这个星期客户问到一个很有趣的问题,是关于如何为第二个、第三个从库选择主库的。在一个数据库主从系统中,我们以前总是把第一个数据库作为 所有从库的主库,这很简单,也是目前实际执行的最佳方案,但我现在有点犹豫。我们知道,在线系统的从库重定向是复杂和困难的,尤其是在凌晨三点面对不同情 况的失败时,哪怕我们使用MMM或者其他工具。而把第一个从库作为第二、第三个,乃至其他所有从库的主库,则会使从库切换为主库的工作变得简单,因为这时 第二级从库不必做重定向。

新方案好的一面是,二级从库可以维持它们所有的SET MASTER TO,和日志位置等配置不变。这大大简化了主库故障转移的操作。这样在主库发生故障的时候,只需要进行简单的读写IP变更,而前一种方案则经常需要对真正 的主库做大量的故障排除工作。另外,在主库故障的情况下,该方案大大简化了数据库故障转移高可用性自动化工作。

但是另一方 面,它引入了第二个单点故障 – 第一个从库。在原来的方案中,可以通过简单的可读写声明和所有其他从库的重定向,来将任一台从库提升为主库。任何一台最下级节点的从库出问题都是很容易处 理的,只需要从应用的数据库池中去除掉有问题的从库即可。但是如果作为其他从库的主库,也就是第一台从库有问题,那么所有其他的从库都要重定向到主库或者 其他的从库。在这种情况下,由于所有的更新都是通过单点故障的第一台从库来传递的,所以实际上所有的从库将会一起无法得到新的数据。虽然,所有的读取操作 可以继续,应用依然可用(不同于主库不可用的情况,依然可读写),但由于读取的是老数据,很快就会成为一个极其严重的问题。

我不确定哪一种方案好,哪一种不好,但这是一个很值得思考的有趣问题。就现在来说我们还会继续使用简单的一主多从结构,并且不断思考如何去改进和简化这个方案。

另 一个相关的话题是多数据库系统中虚拟IP地址的问题。在这方面我们还没有最合适的方案,暂时在所有数据库系统中使用真实IP,即使这会使故障转移和IP切 换更加困难,特别是在读写分离的系统中。但是使用真实的IP能够使系统变得易于设置和管理,同时必须指出,方案的简单化会避免一些额外的故障可能,而实际 上我们很少遇到需要做故障切换的情况,目前的方案已经工作的很好了。但是另一方面不应忘记,我们致力于设计和搭建世界上最好、最快的系统。