死磕数据库系列（二十二）：MySQL 数据库机房架构与跨城容灾

点关注公众号，回复“1024”获取2TB学习资源！

今天我将详细的为大家介绍 MySQL 数据库的机房架构与跨城容灾相关知识，希望大家能够从中收获多多！如有帮助，请点在看、转发支持一波！！！

我们在实际生产环境中，要求不允许丢失任何数据。也就是说，当 MySQL 数据库由于各种原因而无法使用时（发生宕机、网络异常等），不仅需要快速恢复业务，还需要确保数据一致性。

本文主要讲解数据库机房架构与跨城容灾，包括主从复制的强一致性、同城多活、两地三中心、三地五中心、数据兜底逻辑等进行逐步讲解。

容灾级别

高可用性用于处理各种停机问题，停机时间可分为服务器停机、机房停机，甚至城市停机。

机房级宕机：例如机房光纤被阻断、切断，机房整体停电、主备或双备用电源也不可用；

城市级宕机：一般指整个城市的进出口网络和骨干交换机发生故障（这种故障的概率很小）。

如果我们综合考虑，高可用性将成为一种灾难恢复机制，相应的高可用性体系结构的评估标准将提高。主要有三种方案：机房容灾、同城容灾、多地容灾

机房容灾：机房内的数据库服务器不可用，因此切换到同一机房的数据库服务器，以确保业务连续性；

同城容灾：机房不可用，切换本地机房数据库服务器，确保业务连续性；

多地容灾：单个城市的机房整体不可用。切换到跨城市机房的数据库实例以确保业务连续性。

同城多活：一地三中心

同城多活原理

本文主要是同城和跨城的容灾设计，事实上，同城双服务器（同城双活）热备系统与上述文章中双服务器热备用系统没有本质区别，但物理距离要远得多，同城专用网速仍然很快。双机热备份提供灾难恢复能力，双机互备份避免了过度的资源浪费。

这种设计没有考虑到机房网络的抖动，如果机房1和机房2之间的网络抖动，则事务提交需要从机房2中的服务器接收日志，因此事务提交将被挂起。同时机房网络抖动非常普遍，因此同城灾备核心业务应采用多活架构。如下图所示：这种架构如果三个机房位于一个城市，则称为“一地三中心”。如果它们位于两个相邻的城市，则称为“两地三中心”。然而，这种同城/同大区灾难恢复要求机房网络之间的延迟不应超过5ms。

数据的副本存储在三个机房中，这里，MySQL的 rpl_semi_sync_master_wait_for_slave_count 半同步复制参数，如果count设置为1，则只要一台半同步备用计算机接收到日志，就可以提交主服务器上的事务。

这种设计确保了除主机房外，其他机房中的数据至少是一个完整的数据。

这样即使机房1和机房2之间存在网络抖动，因为机房1与机房3之间的网络非常好，因此不会影响主服务器上事务的提交。

如果机房1的出口开关或光纤发生故障，那么可以将故障转移到机房2或机房3，因为至少有一条数据是完整的。

一地三机房架构

机房2和机房3中的数据用于确保数据一致性，但是，如果要实现读/写分离或备份，则需要为异步复制引入备用节点。因此，生产环境中整体结构如下：从图中可以看出，我们添加了两个异步复制节点来分离业务的读写。此外，我们还引入了一个延迟备用机，用于从机房3中的备用机进行异步复制，以从数据删除错误中恢复。由于机房1中的主服务器向四个从属服务器发送日志，因此网卡可能会成为瓶颈，一般需要万兆网卡。更多关于MySQL学习的文章，请参阅：死磕数据库系列之 MySQL ，本系列持续更新中。

两地三中心

只需在两城三中心，通过不同城市设置三个机房，当主服务器停机时，数据库将切换到跨城市，跨城市之间的网络延迟超过25ms。

三地五中心

跨城灾难恢复一般设计为“三地五中心”架构，如下图所示：如上图所示，机房1和机房4位于城市1；机房2和机房5位于城市2；机房3位于3号城市，三个城市之间的距离超过200公里，一般允许延迟超过25毫秒。由于有五个机房，ACK设置为2，以确保至少一条数据在两个机房中具有数据。这样，当城市级故障发生时，城市2或城市3中至少有一个完整的数据。