关于MySQL从库扩展的探索方案分析

　［导读］本文主要介绍Booking网站在业务发展过程中碰到MySQL主库挂载几十甚至上百个从库时探索的解决方案：使用Binlog Server。Binlog Server可以解决五十个以上从库时主库网络带宽限制问题，并规避传统的级联复制方案的缺点；同时介绍了使用Binlog Server还可以用于优化异地机房复制和拓扑重组后的主库故障重组。作者探索问题循序渐进的方式以及处理思路值得我们学习。
　　Booking网站后台有着非常复杂的MySQL主从架构，一台主库带五十个甚至有时带上百个从库并不少见。当从库到达这个数量级之后，一个必须重点关注的问题是主库的网络带宽不能被打满。业界有一个现成的但是有缺陷的的解决方案。我们探索了另外一种能更好适应我们需求的方案：Binlog Server。我们认为Binlog Server可以简化灾难恢复过程，也能使故障后从库迅速升级为新主库变得容易。下面会详细描述。
　　一个MySQL主库带多个复制的从库的时候，每次对主库的修改都会被每个从库请求复制，提供大量二进制日志服务会导致主库的网络带宽饱和。产生大量二进制日志的修改是很常见的，下面是两个例子：
　　在使用行模式binlog日志复制方式的实例中执行大事务删除操作对一个大表执行在线结构修改操作（online schema change）
　　在图1的拓扑图中，假设我们在一个MySQL主库上部署100个从库，主库每产生1M字节的修改每秒都会产生100M字节的复制流量。这和千兆网卡的流量上线很接近了，而这在我们的主从复制结构中很常见。
　　
　　图1： 多从库的MySQL主从架构
　　这个问题的传统解决方案是在主库和它的从库之间部署中继主库。在图2的拓扑部署中，与很多从库直接连到主库不同的是我们有几个从主库复制的中继主库，同时每个中继主库有几个下级从库。假设有100个从库和10个中继主库，这种情况下允许在打满网卡流量之前产生10倍于图1架构的二进制日志。
　　
　　图2： 包含中继主库的MySQL主从架构
　　然而，使用中继主库是有风险的：
　　中继主库上的主从复制延迟将影响它的所有从库。 如果一个中继主库出现异常，所有该中继主库的从库将停止复制并必须重新初始化，［1］ （这会带来很高的维护成本并有可能产生在线故障，译者注）
　　针对图2第二个问题我们可以做深入研究，一个思路是，如果M1出现故障，可以把它的从库的主库配置指向到其他中继主库，但是没那么简单。
　　S1从M1复制的二进制日志依赖于M1M1和M2有不同的二进制日志位置（这两个库是不同的数据库，在同一时间二进制日志状态、位置可能不同，译者注） 手工推进S1的二进制日志位置到M2是非常难而且可能导致数据不一致。
　　GTID可以协助我们指向从库，但是它不能解决第一个关于延迟的问题。
　　实际上我们不需要中继主库的数据，我们只是需要提供Binlog二进制日志服务。同时，如果M1和M2可以提供二进制日志服务并且日志位置是相同的，我们可以很容易地交换各自的从库。根据这两点观察，我们构思了Binlog Server二进制日志服务。
　　Binlog Server替代图2中的中继主库，每个Binlog Server做如下事情：
　　从主库下载二进制日志与主库使用相同结构（文件名和内容）保存二进制日志到磁盘提供二进制日志给从库就像它们是这些从库的二级主库
　　当然，如果一个Binlog Server异常了，我们可以很容易地把它的从库指向到其他Binlog Server就可以。更惊喜的是，由于这些Binlog Server没有本地数据的变化，只是给下游提供日志流，相对有数据的中继主库来说，可以很好的解决延迟的问题。
　　我们与SkySql合作实施了Binlog Server作为一个模块的MaxScale的插件框架。你可以阅读这篇博客上的介绍SkySql MySQL复制，MaxScale和Binlog Server。