面试题：MySQL主从复制在复杂高可用架构中的应用与故障处理

Question

在一个包含多个从库、读写分离且具备自动故障转移机制的复杂MySQL高可用架构中，主从复制如何与其他组件协同工作以保障系统的高可用性？假设主库突然崩溃，且部分从库数据同步存在延迟，详细说明整个故障恢复和数据修复过程中涉及的技术细节和操作步骤。

Answer 1

1. 故障检测：
   • 监控组件：通常有专门的监控工具（如MHA、Orchestrator等）持续监测主库的健康状态。通过定期向主库发送心跳包（例如使用MySQL的ping命令），如果在一定时间内未收到响应，监控组件判定主库崩溃。
2. 自动故障转移：
   • 选举新主库：
     • 基于日志位点：监控组件会检查从库的复制状态，优先选择复制延迟最小、拥有最新二进制日志位点（relay - log位点与主库bin - log位点差距最小）的从库作为新主库。例如，MHA通过解析从库的show slave status信息来获取这些数据。
     • 权重设置：在一些情况下，可以根据从库的硬件性能、网络条件等设置权重，监控组件按照权重优先选择合适的从库。
   • 切换过程：
     • 停止从库复制：监控组件向选中的从库发送命令停止其复制线程（STOP SLAVE）。
     • 提升为新主库：执行RESET MASTER命令，清除该从库原有的复制关系，使其成为新的主库，新主库开始生成自己的二进制日志。
     • 更新配置：修改应用程序的数据库连接配置，将写操作指向新主库。这可以通过配置中心（如Consul、Zookeeper等）来动态更新，应用程序从配置中心获取最新的主库连接信息。
3. 数据同步修复：
   • 追赶同步：
     • 获取新主库位点：其他从库（数据同步延迟的从库）通过CHANGE MASTER TO命令，将主库地址更新为新主库地址，并获取新主库当前的二进制日志文件名和位点信息。
     • 启动复制：执行START SLAVE命令，从库开始从新主库指定的位点处开始复制数据，逐步追赶新主库的数据。
   • 数据一致性校验：
     • 工具使用：在数据同步完成后，可以使用pt - table - checksum等工具来校验主从库数据的一致性。该工具通过对表数据进行哈希计算，对比主从库的哈希值来判断数据是否一致。
     • 修复操作：如果发现数据不一致，根据具体情况进行修复。例如，如果是因为复制延迟导致部分数据未同步，可以通过手动重放二进制日志（在确保安全的前提下），或者使用主从库数据同步工具（如pt - osc等）来进行数据修复。
4. 重新配置主从关系：
   • 调整复制拓扑：根据系统架构要求，可能需要重新调整主从关系。例如，可能需要将新主库的部分从库提升为二级主库，构建更复杂的多主多从架构。
   • 配置复制参数：检查并调整从库的复制参数，如slave - net - timeout（从库等待主库响应的超时时间）、master - heartbeat - period（主库发送心跳包的间隔时间）等，以确保复制的稳定性和高效性。