面试题：MySQL 复杂场景下复制配置策略优化

Question

在一个具有多数据中心且网络延迟不一致的复杂 MySQL 架构中，基于推荐的复制配置策略，如何设计和优化复制拓扑以实现高效的数据同步，同时兼顾灾难恢复和数据一致性，阐述具体的配置思路和关键参数调整。

Answer 1

设计复制拓扑思路

1. 主从复制：
   • 在每个数据中心设置一个主库，承担写入操作。其他数据中心的库作为从库，接收主库的二进制日志并应用，实现数据同步。这样可以分散写入负载，减少单个主库的压力。
   • 例如，假设存在三个数据中心 A、B、C，分别设置主库 Master_A、Master_B、Master_C，每个主库对应其他数据中心的从库。
2. 级联复制：
   • 对于网络延迟较高的从库，可以采用级联复制方式。即让延迟较小的从库作为中间节点，将主库的二进制日志中继给延迟较大的从库。这样可以减少主库与高延迟从库之间的直接交互，提高整体复制效率。
   • 比如，数据中心 D 的从库延迟较高，可让距离较近且延迟较小的数据中心 B 的从库作为中继，将日志传递给数据中心 D 的从库。
3. 环形复制：
   • 构建环形复制拓扑，每个数据中心的主库与相邻数据中心的主库进行双向复制。这种方式在一定程度上可以提高数据的可用性和灾难恢复能力。当某个主库出现故障时，其他主库可以继续提供服务，并且数据可以通过环形路径进行同步。
   • 例如，数据中心 A、B、C 形成环形，Master_A 与 Master_B 双向复制，Master_B 与 Master_C 双向复制，Master_C 与 Master_A 双向复制。

关键参数调整

1. 主库参数：
   • log - bin：开启二进制日志，确保主库记录所有的写操作，格式设置为 ROW 模式，以提高数据复制的准确性和效率。例如：log - bin = /var/log/mysql/mysql - bin.log
   • server - id：每个主库设置唯一的 server - id，用于在复制拓扑中标识自身。比如 server - id = 1（数据中心 A 的主库），server - id = 2（数据中心 B 的主库）等。
   • sync - binlog：设置为 1，确保每次写操作都同步二进制日志到磁盘，保证数据安全性，但可能会对性能有一定影响。可根据实际情况权衡设置。
2. 从库参数：
   • server - id：同样需设置唯一，与主库不同。如从库 Slave_A1（数据中心 A 内的从库）设置为 server - id = 11。
   • relay - log：指定中继日志路径，记录从主库接收的二进制日志。例如：relay - log = /var/log/mysql/mysql - relay.log
   • read - only：设置为 1，确保从库只读，防止误写入操作破坏数据一致性。
   • slave - net - timeout：根据网络延迟情况合理设置，该参数定义了从库等待主库发送事件的超时时间。对于网络延迟较高的情况，适当增大此值，避免因短暂网络波动导致复制中断。比如设置为 60（默认 30 秒）。
3. 全局参数：
   • gtid - mode：开启全局事务标识符（GTID）模式，gtid - mode = ON。GTID 可以简化复制管理，确保事务在整个复制拓扑中的一致性，方便故障恢复和主从切换。
   • enforce - gtid - consistency：设置为 ON，保证 GTID 模式下的一致性，防止出现不一致的事务状态。