面试题：MySQL：从另一服务器启动复制时，处理主从数据不一致的策略及实践

Question

假设在从另一服务器启动MySQL复制过程中，发现主从数据出现不一致情况。阐述可能导致不一致的原因，并说明如何检测这种不一致，以及给出至少两种处理主从数据不一致的实际操作策略。

Answer 1

可能导致主从数据不一致的原因

1. 网络问题：主从服务器之间网络延迟、丢包等，导致部分二进制日志（Binlog）传输不完整或延迟。
2. 主库故障：主库在写入数据后，还未将Binlog完全同步给从库就发生故障，可能导致数据丢失。
3. 从库异常：从库在执行中继日志（Relay Log）时出现错误，如数据类型不匹配、存储引擎错误等，导致中继日志执行中断或部分未执行。
4. 手动操作：在主从复制运行过程中，手动在从库上执行了写入操作，破坏了复制的一致性。
5. 版本差异：主从服务器MySQL版本不一致，某些特性或功能在不同版本实现上有差异，影响数据复制。

检测主从数据不一致的方法

1. 对比工具：使用专门的数据库对比工具，如pt-table-checksum（Percona Toolkit工具集中的一员）。它通过在主库上生成校验和，然后在从库上进行对比，能快速定位数据不一致的表和行。
2. COUNT对比：在主从库上对关键表执行 COUNT(*) 操作，对比结果。如果结果不一致，初步判断存在数据不一致情况。然后可以进一步对表中的关键列进行分组 COUNT 统计，缩小不一致数据范围。
3. 基于Binlog和Relay Log对比：对比主库的Binlog和从库的Relay Log，查看从库是否完整接收并应用了主库的所有日志事件。不过这种方法较为复杂，需要对日志格式和内容有深入了解。

处理主从数据不一致的实际操作策略

1. 重新同步数据：
   • 停止从库复制：STOP SLAVE;
   • 清空从库数据（确保备份重要数据）：根据数据库情况，可使用 TRUNCATE 或 DELETE 语句清空从库相关表数据。
   • 在主库上记录当前Binlog位置：执行 SHOW MASTER STATUS; 记录 File 和 Position。
   • 从主库导出数据：使用 mysqldump 工具导出主库数据，例如 mysqldump -uroot -p --master-data=2 --single-transaction --all-databases > master_dump.sql。--master-data=2 会在导出文件中记录Binlog位置，--single-transaction 保证导出数据的一致性。
   • 将导出文件传输到从库并导入：使用 scp 等工具传输文件，然后在从库上执行 mysql -uroot -p < master_dump.sql 导入数据。
   • 配置从库复制：根据主库记录的Binlog位置，在从库执行 CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='复制用户', MASTER_PASSWORD='复制密码', MASTER_LOG_FILE='记录的File', MASTER_LOG_POS=记录的Position;
   • 启动从库复制：START SLAVE;
2. 增量同步：
   • 确定不一致数据范围：通过对比工具或统计方法，找出主从库之间不一致的数据。例如，使用pt-table-checksum定位不一致的行。
   • 从主库导出不一致数据：使用 mysqldump 结合 WHERE 条件，导出主库中不一致的数据。例如 mysqldump -uroot -p --where="id IN (不一致数据的id列表)" your_database your_table > incremental_dump.sql。
   • 将增量数据传输到从库并导入：传输文件后，在从库执行 mysql -uroot -p your_database < incremental_dump.sql 导入数据。
   • 检查并修复：再次使用检测方法确认数据是否一致，若仍不一致，重复上述步骤直至数据一致。