1、经常出问题，如果是数据库服务器经常出问题，如宕机的话，那么写个小程序，专门监控数据库服务器是否正常，如果不正常则通知你的服务器哪一台不正常，如果两台都不正常了，你的服务器可以选择罢工了。

2、服务器是知道当前哪个数据库服务器是正常的了，一般而言，两个都是正常的。因为你数据库服务器已经实现同步了（这里你的那个同步可能要修改下，同步的周期要缩短点，而且互镜像）。所以服务器的代码里面就可以偷懒了，直接生成一个随机数，然后对2取模，如果等于零，访问A数据库服务器，如果不等于零，访问B数据库服务器。当然这个2，你服务器需要维护的。因为如果挂掉了一个数据库服务器，这个时候你就该对1取模了，当然永远是零了，于是永远访问没坏的那个数据库服务器了。全坏了，罢工吧。

这个解决方案简单吧，而且对你现有的产品改动很少。如果你把那个初始的2做成可配置的，那么以后还可以继续增加数据库，水平扩展。但这个方案里面也有一个难点，就是你要实现两个数据库的互镜像。不过，相信谷歌，去找下，资料还是有的。

从我的优化经验来看，99%不是说数据库服务器真的扛不住了，而是表设计不合理和SQL写的太烂。找出Top100的最耗性能的SQL搞定，我可以肯定你的一台数据库服务器也够用了。

另外你的看瓶颈在哪儿，不改SQL和表的话，CPU高都搞几个CPU，IO高就多插几块硬盘。将频繁读的数据分散开。

纳斯达克的即时交易才两个4节点的SQLserver集群就搞定了。