面试题：MariaDB 复制中的故障处理

Question

在 MariaDB 主从复制环境中，如果主库突然出现故障，应该如何进行故障恢复并尽量减少数据丢失？请详细描述操作步骤和涉及到的技术点。

Answer 1

故障恢复操作步骤

1. 确认主库故障：通过监控工具、应用报错等方式，确认主库确实发生故障，无法提供正常服务。
2. 选择新主库：
   • 通常选择从库中复制延迟最小的作为新主库。可以通过查看从库的 SHOW SLAVE STATUS 输出中的 Seconds_Behind_Master 字段来判断延迟情况，该值越小表示延迟越小。
   • 若存在多个从库延迟相近，可根据硬件性能、网络拓扑等因素综合选择。
3. 提升新主库：
   • 在选定的从库上执行 STOP SLAVE 命令，停止复制线程。
   • 执行 RESET MASTER 命令，重置主库信息，清除原有的复制相关日志和位点信息。此操作会生成新的二进制日志文件和位点。
4. 配置其他从库指向新主库：
   • 在每个需要重新配置的从库上执行 STOP SLAVE 命令。
   • 根据新主库的信息，使用 CHANGE MASTER TO 命令重新配置主库连接信息，包括新主库的主机名、端口、复制用户及密码、二进制日志文件名和位点。例如：

CHANGE MASTER TO
    MASTER_HOST='new_master_host',
    MASTER_PORT=3306,
    MASTER_USER='replication_user',
    MASTER_PASSWORD='replication_password',
    MASTER_LOG_FILE='new_master_binlog.000001',
    MASTER_LOG_POS=1234;

这里的 MASTER_LOG_FILE 和 MASTER_LOG_POS 需根据新主库的实际二进制日志文件名和位点填写，可通过在新主库上执行 SHOW MASTER STATUS 获得。 - 执行 START SLAVE 命令，启动从库的复制线程，使其开始从新主库复制数据。 5. 检查复制状态：在每个从库上执行 SHOW SLAVE STATUS 命令，确保 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，并且 Seconds_Behind_Master 为 0 或接近 0，表明复制正常运行。

涉及技术点

1. 复制原理：理解 MariaDB 主从复制基于二进制日志（binary log）的原理，主库将数据修改记录到二进制日志，从库通过 I/O 线程读取主库二进制日志并写入中继日志（relay log），再由 SQL 线程执行中继日志中的事件来同步数据。
2. 位点信息：主库的二进制日志文件名和位点（log file 和 log position）是从库复制数据的关键信息，在故障恢复重新配置复制时，需要准确获取和使用这些信息，以确保从库能从正确位置开始复制。
3. 复制线程管理：STOP SLAVE 和 START SLAVE 命令用于控制从库的复制线程，在重新配置复制环境时需要正确操作这些线程。
4. 主库切换影响：执行 RESET MASTER 命令会重置主库的二进制日志，原有的二进制日志文件可能被删除或覆盖，因此在选择新主库和提升新主库操作时要谨慎，确保不会导致数据丢失。同时，从库重新配置指向新主库后，可能需要一定时间来追赶数据，期间应用可能会受到一定影响，需考虑合适的业务应对策略。