binlog复制的灾备设计

［导读］本文主要介绍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复制的二进制日志依赖于M1

• M1和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。

另外一个案例1：避免远程站点上的深度嵌套复制 
Binlog Server还能用于规避远程站点上的深度嵌套复制的问题。

假设有两个不一样地域机房，每一个机房须要四个数据库服务器，当网络带宽须要特别关注的时候(E、F、G和H在远程站点)，图3的拓扑图是一个典型的部署方式。

图3: 使用中继主库部署的MySQL异地主从架构

可是这个拓扑结构会受到上述讨论问题的影响(复制延迟将从E传递至F、G和H，同时E异常以后，F、G、H就会失败)。若是咱们用图4的架构就好不少，可是这种架构须要更多的网络带宽，并且一旦主复制节点发生问题，异地机房从库须要重建一套新的主从架构。

图4: 不包含中继主库的异地机房MySQL主从部署

在异地机房主从架构中使用Binlog Server，咱们能够综合上面两种方案的优点(低带宽使用和中继数据库不产生延迟)。拓扑图以下面图5。

图5: 包含Binlog Server的异地机房MySQL主从架构

图5中的MySQL主从架构中，Binlog Server (X)看起来是一个单点，可是若是它异常了, 从新启动另一个Binlog Server是很容易的。并且也能够像图6示例的在异地机房运行两个Binlog Servers。在这个部署中，若是Y异常了，G和H能够指向到X，若是X异常了，E和F能够指向到Y，Y能够指向到A。

图6:包含两个Binlog Server的异地机房MySQL主从架构

运行Binlog Servers其实不须要更多更好的硬件，在图6中，X、E、Y、G能够安装在同一台硬件服务器上。

最后，这种架构(有1个或2个Binlog Servers)有一个颇有意思的属性：若是主站点的主库发生故障，异地机房从库能够收敛到彻底一致的状态(只要X服务器的二进制正常)。这使得重组MySQL主从架构变得很容易：

• 任何一个从能够成为新主库

• 新主库的二进制日志位置在发送写以前会标注出来

• 其余的节点成为新主库的从库，在以前提到的二进制日志位置。

另外一个案例2：简单的高可用实现

Binlog Server能够用于高可用架构的实现。假如图7主库故障了，咱们但愿尽快选出新的主库，咱们能够部署GTIDS或使用MHA，可是他们都有缺点。

图7: 6个从库直连主库的MySQL主从架构

• 若是咱们像图8同样在主库和从库之间部署一个Binlog Server。

• 若是X异常，咱们能把全部从库指向A

• 若是A异常，全部从库会达到一个一致的状态，使得将从库重组成一个复制树变得很容易(像上面提到的)。

图8: 包含Binlog Server的MySQL主从架构

若是咱们但愿实现高扩展性和高可用性，咱们能够部署成图9的主从架构。

图9:包含多个Binlog Servers的MySQL主从架构

若是一个Binlog Server异常，它的从库将指向到其余Binlog Servers。若是I1失败了：

• 咱们找到有跟多二进制日志的Binlog Server (咱们假定在这个例子中是I2)

• 咱们将其余Binlog Servers 指向到I2像图10同样。

• 当全部的从库都达到一个共同的状态，咱们从新组MySQL主从架构。

图10: 主库异常后调整Binlog Server指向的MySQL主从架构

结论：

咱们在咱们的MySQL主从架构中引入了一个新的组件：Binlog Server。它使从库水平扩展不会超越网络带宽的的限制，同时也没有传统的级联复制解决方案的缺点。 
咱们以为Binlog Server还能够用于解决其余两个问题：远程站点复制和拓扑重组后的主库故障重组。后续咱们将带来的Binlog Server的其余使用案例，敬请期待更多细节。

[1] 从库从新初始化的大量工做能够经过GTIDS或经过采用高可用的中继主库（DRBD或Netapp的Snapshot）来避免，可是这两个解决方案分别会带来新的问题。