技术项目 - MySQL多从系统的主库选择

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

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

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

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

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