面试题：MariaDB复制日志管理中的故障恢复与一致性保证

Question

假设在MariaDB主从复制环境中，由于突发故障导致主库和从库的日志出现不一致情况。请设计一套详细的故障恢复方案，利用日志管理机制来确保数据的一致性，包括如何定位不一致点、选择合适的恢复工具和技术，以及在恢复过程中如何最小化对业务的影响。同时，阐述在日常运维中，如何通过日志管理预防此类故障的发生。

Answer 1

故障恢复方案

1. 定位不一致点

1. 查看主从状态
   • 在主库执行 SHOW MASTER STATUS;，记录 File 和 Position。
   • 在从库执行 SHOW SLAVE STATUS \G;，查看 Relay_Master_Log_File 和 Exec_Master_Log_Pos 与主库对比，若不一致则初步定位问题。
2. 分析二进制日志
   • 利用 mysqlbinlog 工具查看主库二进制日志，找到从库落后或不一致的位置。例如，在主库上通过命令 mysqlbinlog --start - position = <主库当前Position> <主库二进制日志文件名> 查看相关日志内容，对比从库相应位置的日志。
3. 数据校验
   • 可以使用 pt - table - checksum 工具对主从库数据进行校验。在主库上执行 pt - table - checksum h = 127.0.0.1,u = root,p = password --databases <数据库名>，它会生成校验和并记录到 percona.checksums 表中。然后在从库上执行同样命令，对比校验和结果，找出不一致的数据表及相关行。

2. 选择合适的恢复工具和技术

1. 基于二进制日志重放
   • 若从库落后，在从库停止复制 STOP SLAVE;。
   • 确定从库需要重放的日志位置，执行 CHANGE MASTER TO MASTER_LOG_FILE = '<主库二进制日志文件名>', MASTER_LOG_POS = <主库当前Position>;。
   • 重新启动复制 START SLAVE;，从库会从指定位置开始重放主库二进制日志，从而恢复数据一致性。
2. 全量数据同步 + 增量恢复
   • 如果不一致情况较复杂，先进行全量数据同步。例如使用 mysqldump 工具在主库上备份数据 mysqldump - u root - p --all - databases > master_backup.sql，将备份文件传输到从库并恢复 mysql - u root - p < master_backup.sql。
   • 然后获取主库当前二进制日志位置，在从库通过 CHANGE MASTER TO 命令设置从库从主库当前位置开始复制增量数据。

3. 最小化对业务影响

1. 选择合适时间
   • 尽量选择业务低峰期进行恢复操作，减少对正常业务的影响。
2. 双活或多活架构配合
   • 如果有双活或多活架构，可以先将流量切到其他正常的节点，然后对故障的主从节点进行恢复操作。恢复完成后再将流量切回或重新均衡。
3. 在线恢复
   • 在进行基于二进制日志重放等恢复操作时，一些数据库允许在从库处于复制状态下进行部分调整，尽量减少业务中断时间。

日常运维预防措施

1. 日志备份策略

1. 定期备份二进制日志
   • 设置合理的备份周期，例如每天凌晨备份主库二进制日志。使用 PURGE BINARY LOGS BEFORE '2024 - 01 - 01 00:00:00'; 等命令结合定时任务清理过期日志，同时使用 mysqlbinlog 工具备份重要日志。
2. 备份中继日志
   • 从库也要定期备份中继日志，防止中继日志损坏丢失导致复制中断。

2. 监控机制

1. 主从状态监控
   • 使用 SHOW SLAVE STATUS \G; 命令结合脚本定时检查从库复制状态，如 Seconds_Behind_Master 等关键指标。若指标异常，及时发出告警通知运维人员。
2. 日志空间监控
   • 监控主从库二进制日志和中继日志占用空间，防止因磁盘空间不足导致日志写入失败，引发主从不一致。

3. 配置优化

1. 合理设置复制参数
   • 在主库配置文件中合理设置 sync_binlog 参数，例如设置为 1，确保每次事务提交都同步二进制日志到磁盘，保证日志的完整性。
   • 在从库配置文件中合理设置 relay_log_recovery 参数为 1，当从库重启时，自动重新获取主库日志并继续复制，防止中继日志损坏丢失影响复制。