面试题：MySQL 故障转移与故障恢复流程 - 高级难度

Question

假设你正在维护一个高可用的 MySQL 集群，使用 MHA（Master High Availability）进行故障转移。当检测到主库故障时，MHA 是如何自动完成故障转移的？请详细描述其内部机制和关键操作步骤。此外，在故障转移过程中，可能会遇到哪些数据一致性问题，如何解决？

Answer 1

MHA 自动完成故障转移的内部机制和关键操作步骤

1. 监控节点检测故障：
   • MHA 的监控节点（通常是 manager 节点）通过心跳机制持续监测主库的状态。它会定期向主库发送特定的查询（如 SELECT 1）来确认主库是否存活。如果在一定时间内没有收到主库的响应，监控节点就判定主库发生故障。
2. 确定新主库：
   • 监控节点会从配置的从库列表中选择一个合适的从库作为新的主库。选择标准通常基于多个因素，例如从库的复制延迟、服务器性能等。一般优先选择复制延迟最小的从库。
   • 监控节点通过 SHOW SLAVE STATUS 等命令获取从库的复制状态信息，评估每个从库与主库数据的同步程度。
3. 停止从库复制：
   • 监控节点会向所有从库发送停止复制的命令（STOP SLAVE），以防止在故障转移过程中从库继续从已经故障的主库接收数据，避免数据不一致。
4. 提升新主库：
   • 监控节点向选定的从库发送命令，将其提升为新的主库。这通常涉及执行 RESET MASTER 命令，清除该从库之前作为从库的复制相关配置，使其成为主库。
5. 重新配置从库：
   • 监控节点向其余从库发送命令，重新配置它们以指向新的主库。这包括设置新主库的连接信息（如 CHANGE MASTER TO 语句，指定新主库的 IP、端口、日志文件名和位置等），然后启动复制（START SLAVE）。
6. 应用中继日志：
   • 在提升新主库之前，监控节点会检查新主库上的中继日志（relay log），并应用尚未应用的中继日志，以确保新主库的数据尽可能完整。对于其他从库，也会确保它们应用完所有中继日志后再重新指向新主库。

故障转移过程中可能遇到的数据一致性问题及解决方法

1. 数据丢失问题：
   • 问题描述：在主库故障时，如果部分事务已经提交，但尚未完全同步到从库，在故障转移后，这些事务的数据可能丢失。
   • 解决方法：
     • 配置 MySQL 的半同步复制（semi - synchronous replication）。在半同步复制模式下，主库在提交事务前，需要等待至少一个从库确认接收到并写入中继日志，这样可以减少数据丢失的可能性。
     • 可以使用 MHA 的参数 --skip - master - failover - on - binlog - error，当主库故障时，如果从库的中继日志应用出现错误，MHA 不会盲目进行故障转移，避免数据丢失。
2. 数据重复问题：
   • 问题描述：在故障转移过程中，如果处理不当，可能会导致某些事务在新主库和从库上重复执行，造成数据重复。
   • 解决方法：
     • MHA 在提升新主库前，会确保新主库应用完所有中继日志，并且在重新配置从库时，会准确设置复制的起始位置，避免重复应用日志。
     • 合理配置 MySQL 的 GTID（Global Transaction Identifier）模式。GTID 可以唯一标识每个事务，MySQL 在复制过程中会根据 GTID 来判断事务是否已经执行，从而避免重复执行事务。
3. 主从数据不一致问题：
   • 问题描述：由于网络延迟、复制故障等原因，可能导致从库与主库数据不一致，在故障转移后这种不一致可能加剧。
   • 解决方法：
     • 定期使用 pt - table - checksum 等工具检查主从库数据的一致性。该工具会对表数据进行校验和计算，并比较主从库的结果，发现不一致时可以采取相应措施（如重新同步数据）。
     • 配置合适的复制拓扑和参数，如适当调整 slave - net - timeout 等参数，优化网络连接，减少因网络问题导致的复制延迟和数据不一致。