面试题：MySQL高可用性与云服务集成中的故障切换

Question

当将MySQL与云服务集成实现高可用性时，假设云环境下主库所在服务器突然宕机，描述自动故障切换的详细流程以及可能遇到的问题，如何确保数据不丢失或最小化丢失？

Answer 1

自动故障切换详细流程

1. 检测节点故障：在云环境中，一般会部署监控组件（如MHA中的Manager节点、Orchestrator等）持续监测MySQL主库所在服务器的状态。当主库服务器宕机时，监控组件通过心跳检测机制（如基于TCP连接、特定的SQL查询等方式）感知到主库无响应，从而判定主库发生故障。
2. 选举新主库：监控组件启动选举机制。如果使用MHA，Manager节点会根据预先配置的从库优先级（如根据复制延迟、服务器性能等因素设置权重），从多个从库中选举出一个新的主库。若采用Orchestrator，它会基于自身的选举策略（如选择延迟最小的从库等）挑选出新主库。
3. 切换主库：选举完成后，监控组件向选中的从库发送命令，使其提升为主库（例如执行CHANGE MASTER TO命令解除与原主库的连接，并将自身设置为主库模式）。同时，监控组件会通知其他从库将复制源切换到新主库。
4. 恢复服务：应用程序的连接池（如使用的是Java的HikariCP等）会检测到数据库连接异常，通过配置的重连机制，重新连接到新的主库，从而恢复业务服务。

可能遇到的问题

1. 数据不一致：由于主从复制存在一定延迟，在主库宕机瞬间，可能存在部分已提交事务还未同步到从库，导致新主库数据比原主库少，出现数据不一致。
2. 脑裂问题：在网络分区情况下，监控组件可能会误判主库故障，选举出多个新主库，造成数据混乱。
3. 切换时间过长：选举过程中如果策略复杂或网络不稳定，导致切换时间过长，业务会有较长时间的数据库服务不可用。
4. 监控组件故障：如果监控组件所在服务器自身出现故障，可能无法及时检测到主库宕机，影响故障切换及时性。

确保数据不丢失或最小化丢失的方法

1. 设置同步复制：在MySQL 5.7及以上版本，可以配置组复制（Group Replication）或半同步复制（Semi - synchronous Replication）。半同步复制确保至少有一个从库接收到并写入主库发送的二进制日志事件后，主库才会确认事务提交，大大减少数据丢失风险。组复制则是基于Paxos算法实现多节点间数据强一致性，进一步保障数据不丢失。
2. 定期备份与日志归档：定期进行全量备份（如每周一次），并开启二进制日志归档（log - bin）。在故障发生后，可以通过备份和归档日志进行数据恢复，尽量减少数据丢失。
3. 优化选举策略：在监控组件配置中，优先选择复制延迟小、数据完整性高的从库作为新主库，降低数据丢失可能性。
4. 多监控组件部署：部署多个监控组件实例，并采用分布式部署方式，防止单个监控组件故障影响故障检测与切换。
5. 网络优化：确保云环境内网络稳定，降低网络分区发生概率，避免因网络问题导致误判和切换异常。