面试题：MySQL复制冗余架构下的故障切换机制

监控方式：
- 心跳检测：通过定期向主库发送简单查询（如 SELECT 1），若在设定时间内未收到响应，标记为主库可能故障。
- 日志监控：监控主库二进制日志（Binlog）的更新情况，若长时间无更新，怀疑主库故障。
- 基于第三方工具：如 MHA（Master High Availability）的 manager 节点会定期监测主库状态。

手动切换：
- 选择新主库：从多个从库中挑选一个作为新主库，优先选择复制延迟最小、硬件性能较好的从库。
- 停止从库复制：在选定的从库上执行 STOP SLAVE 命令，使其不再接收主库的更新。
- 提升为新主库：执行 RESET MASTER 命令，清除原有的复制信息并创建新的二进制日志。
- 通知其他从库：告知其他从库新主库的地址和相关复制配置信息，在其他从库上执行 CHANGE MASTER TO 命令，将主库指向新主库，并执行 START SLAVE 命令恢复复制。
自动切换（以 MHA 为例）：
- MHA manager 检测到主库故障：通过心跳监测机制发现主库无响应。
- 选择新主库：MHA manager 会根据配置和从库状态，挑选一个合适的从库。
- 自动执行切换操作：
  - MHA manager 会在选定从库上执行 STOP SLAVE 和 RESET MASTER。
  - 同时通知其他从库执行 CHANGE MASTER TO 并 START SLAVE。
  - 对于故障主库上未同步到从库的二进制日志，MHA 会尝试通过 SSH 等方式获取并应用到新主库及其他从库。

二进制日志（Binlog）：主库记录所有数据库修改操作到 Binlog，从库通过 I/O 线程读取主库 Binlog 并写入中继日志（Relay Log），SQL 线程再从中继日志读取并应用到从库。故障切换后，新主库开始生成新的 Binlog，从库基于新主库的 Binlog 进行同步。
GTID（全局事务标识符）：如果开启 GTID 模式，每个事务在主库上会生成唯一 GTID，从库通过 GTID 来追踪和应用事务，保证复制的一致性。故障切换时，新主库继承原主库的 GTID 集合，从库根据 GTID 进行同步。

数据一致性：
- 确保在故障切换过程中，已提交的事务不会丢失。在基于 GTID 的复制中，可有效保证这一点。若未开启 GTID，需通过一些手段（如 MHA 收集未同步 Binlog 并应用）来保证数据一致。
- 切换过程中，可能存在短暂的数据不一致窗口，需评估业务对数据一致性的容忍程度。
网络配置：
- 确保新主库的网络配置正确，能被应用程序和其他从库正常访问。
- 检查防火墙、路由等网络设备，确保相关端口（如 MySQL 服务端口）畅通。
应用程序配置：
- 及时更新应用程序的数据库连接配置，将写操作指向新主库，读操作可根据负载情况分配到从库或新主库。
- 可能需要对应用程序进行一些测试，确保其在主库切换后能正常工作。
监控与验证：
- 故障切换完成后，持续监控新主库和从库的状态，包括复制延迟、连接数、性能指标等。
- 验证数据库的完整性，如通过执行一些一致性检查的 SQL 语句或使用专门的数据库验证工具。

星途面试题库