面试题：MySQL主 - 主复制中备库数据一致性维护与故障处理

Question

假设在MySQL的主 - 主复制结构中，备库出现数据不一致的情况，你会从哪些方面去排查原因并解决？同时，如果主库发生故障，备库如何快速切换为主库并保障业务的连续性，请详细说明步骤和可能遇到的问题及解决方案。

Answer 1

排查备库数据不一致原因及解决方法

1. 网络问题
   • 排查：检查主库与备库之间的网络连接是否稳定，可通过 ping 命令、traceroute 等工具查看网络延迟、丢包情况。
   • 解决：若存在网络问题，联系网络管理员解决网络故障，确保主备库之间网络通畅。
2. 主库写入问题
   • 排查：查看主库的二进制日志（binlog）是否正常记录，通过 SHOW BINARY LOGS 查看日志列表，SHOW CREATE TABLE 检查表结构是否正常，确认主库上的数据写入操作是否存在异常（如数据类型不匹配、违反约束等）。
   • 解决：修复主库上的数据写入问题，若 binlog 损坏，可尝试从备份中恢复或修复 binlog。
3. 备库复制设置问题
   • 排查：在备库执行 SHOW SLAVE STATUS \G，检查 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes，Seconds_Behind_Master 的值是否过大。查看复制用户权限是否正确，配置的主库信息（如 MASTER_HOST、MASTER_USER、MASTER_PASSWORD 等）是否准确。
   • 解决：若 Slave_IO_Running 为 No，检查网络及复制用户权限等问题；若 Slave_SQL_Running 为 No，查看错误日志（SHOW ENGINE INNODB STATUS 查看 InnoDB 错误，SHOW WARNINGS 查看 SQL 警告），根据错误提示解决问题，如数据冲突等。如果 Seconds_Behind_Master 过大，可考虑增加备库资源或优化主库写入性能。
4. 数据操作问题
   • 排查：确认是否在备库上进行了非复制相关的写入操作，查看备库的操作日志。
   • 解决：停止在备库上的非复制写入操作，并根据主库数据恢复备库数据，可通过重新搭建复制环境或从主库导出数据导入备库。

主库故障时备库切换为主库及保障业务连续性

步骤

1. 确认主库故障：通过监控工具（如 Nagios、Zabbix 等）或应用反馈确认主库确实发生故障，尝试连接主库，若无法连接且排除网络问题，则确定主库故障。
2. 提升备库为主库：在备库执行 STOP SLAVE；执行 RESET MASTER，清除原有的复制设置并重新生成新的二进制日志；修改数据库配置文件，将服务器角色设置为主库相关配置（如设置合适的 server_id 等）；重启 MySQL 服务使配置生效。
3. 通知应用更新连接配置：将应用程序连接的数据库地址从原主库切换到新主库。
4. 重新配置其他备库：将其他备库重新指向新主库，在其他备库执行 CHANGE MASTER TO 命令，指定新主库的相关信息（如 MASTER_HOST、MASTER_LOG_FILE、MASTER_LOG_POS 等），然后执行 START SLAVE 开启复制。

可能遇到的问题及解决方案

1. 数据一致性问题：在主库故障时，可能存在部分事务未同步到备库。
   • 解决方案：如果应用可以容忍一定的数据丢失，可直接提升备库为主库继续服务；若不能容忍数据丢失，可尝试从主库的最后备份恢复数据，再结合 binlog 进行前滚操作（使用 mysqlbinlog 工具），尽量恢复未同步的事务。
2. 应用连接问题：应用程序可能未能及时更新连接配置，仍尝试连接原主库。
   • 解决方案：设置数据库连接的重试机制，当连接失败时自动尝试连接新主库；同时，在应用更新连接配置期间，可设置一个临时的负载均衡器（如 HAProxy），将请求转发到新主库，待应用全部更新配置后再移除负载均衡器。
3. 新主库性能问题：原备库提升为主库后，可能由于资源限制等原因导致性能下降。
   • 解决方案：提前评估备库资源，在切换前适当增加资源（如 CPU、内存、磁盘 I/O 等）；对新主库进行性能优化，如调整 MySQL 参数（innodb_buffer_pool_size 等）、优化查询语句等。