27 | 主库出问题了，从库怎么办？
在数据库管理系统中，尤其是在使用MySQL这类关系型数据库进行高可用性和数据冗余设计时，主从复制架构是极其常见的选择。这种架构通过将一个数据库实例（主库）的数据实时或异步地复制到一个或多个数据库实例（从库）上，以实现数据的备份、读写分离、负载均衡等目的。然而，当主库遭遇故障或问题时，如何确保业务的连续性和数据的一致性，便成为了数据库管理员和开发者需要面对的重要课题。本章将深入探讨当主库出现问题时，从库应如何应对及后续的处理策略。
一、主库故障的常见类型
在讨论从库如何应对之前，首先需了解主库可能遇到的几类常见故障：
- 硬件故障：如硬盘损坏、服务器宕机等。
- 软件故障：操作系统崩溃、MySQL服务异常终止等。
- 网络问题：主从库之间的网络连接中断，导致复制中断。
- 配置错误：复制配置不当，如binlog未开启、复制用户权限不足等。
- 数据不一致：由于某种原因（如跳过了某些事务的复制）导致主从数据不一致。
二、从库的即时响应措施
一旦检测到主库出现问题，从库虽不能直接修复主库的问题，但可以采取一系列措施来减轻影响，并为后续的恢复工作做准备：
监控与报警：
- 确保监控系统能够及时发现主库故障，并触发报警机制。
- 报警信息应包括故障类型、影响范围及初步判断原因。
停止数据写入（如果适用）：
- 如果应用支持读写分离，且业务允许，可暂时停止向从库写入数据，避免数据进一步混乱。
- 注意，这一操作需谨慎，因为停止写入可能会影响业务功能。
保持从库状态：
- 确保从库正常运行，不因主库故障而中断服务（特别是如果从库承担读请求）。
- 检查并调整从库的复制状态，确保在问题解决前，复制不会进一步出错。
数据一致性校验（可选）：
- 如果条件允许，可以在从库之间进行数据一致性校验，确认从库间数据是否一致。
- 使用如
pt-table-checksum等工具可以帮助完成这一过程。
三、主库恢复策略
主库的恢复是解决问题的核心，根据故障类型的不同，恢复策略也有所不同：
硬件故障：
- 更换损坏的硬件部件，如硬盘、服务器等。
- 恢复系统后，需重新配置MySQL服务，并尝试从备份中恢复数据。
软件故障：
- 重启MySQL服务，检查日志文件确定具体原因。
- 根据错误日志修复配置错误或软件缺陷。
网络问题：
- 检查网络连接，确保主从库之间的网络通畅。
- 如果网络问题复杂，可能需要联系网络管理员协助解决。
配置错误：
- 仔细检查复制配置，确保所有必要的参数都已正确设置。
- 重启复制线程，观察是否能正常同步数据。
数据不一致：
- 使用MySQL的
CHANGE MASTER TO命令重新定位复制起点，跳过错误的事务。 - 如果数据丢失严重，可能需要考虑使用备份文件进行恢复。
- 使用MySQL的
四、从库接管策略
在某些情况下，如果主库无法快速恢复，或者恢复成本过高，可能需要将从库提升为主库来继续提供服务：
选择最佳从库：
- 评估各从库的数据一致性、性能及负载情况，选择最合适的从库进行提升。
- 确保该从库的数据完整性和一致性达到要求。
执行提升操作：
- 停止该从库的复制进程。
- 修改其配置，使其不再作为从库。
- 更新应用配置，将新的主库地址更新到所有依赖该数据库的应用中。
重新配置从库：
- 将其他从库重新配置为指向新的主库进行复制。
- 确保复制过程正常，数据能够持续同步。
数据校验：
- 在完成提升和重新配置后，进行全面的数据校验，确保数据的一致性和完整性。
五、后续处理与预防
故障复盘：
- 组织团队对故障进行复盘，分析故障原因，总结经验教训。
- 编写故障报告，记录故障处理过程和解决方案。
优化复制配置：
- 根据故障处理过程中发现的问题，优化复制配置，提高系统的稳定性和可靠性。
备份与恢复演练：
- 定期进行数据库备份和恢复演练，确保在真实故障发生时能够快速恢复数据。
高可用架构设计：
- 考虑引入更高级的高可用架构，如MySQL Group Replication、ProxySQL等，以增强系统的容错能力和自动恢复能力。
监控与报警系统优化：
- 持续优化监控与报警系统，确保能够及时发现并响应各种潜在问题。
总之，当MySQL主库出现问题时，从库的角色虽以辅助为主，但通过及时响应、数据校验、合理提升及后续优化，可以有效减轻主库故障对业务的影响，保障数据的完整性和服务的连续性。同时，通过持续的优化和演练，可以不断提升系统的稳定性和应对突发情况的能力。
