MST

星途 面试题库

面试题：MariaDB多源复制故障复杂场景处理

在一个使用MariaDB多源复制（Multi - Source Replication）的复杂生产环境中，突然出现了部分从库数据不一致的情况，并且同时伴有某些源库的复制线程间歇性中断。请深入分析这种复杂故障可能产生的原因，以及你将采取什么样的一套系统的故障排查和恢复方案，包括如何验证恢复后的复制环境的正确性和稳定性。
21.6万 热度难度
数据库MariaDB

知识考点

AI 面试

面试题答案

一键面试

故障可能产生的原因

  1. 网络问题
    • 源库与从库之间网络不稳定，导致数据传输中断或丢包，引起复制线程间歇性中断以及数据不一致。例如网络拥塞、网络设备故障等。
    • 不同源库与从库之间的网络延迟差异较大，可能使从库接收数据的顺序和速度不同，进而造成数据不一致。
  2. 源库问题
    • 源库负载过高，导致复制相关操作不能及时完成，出现复制线程间歇性中断。例如大量的写入操作使磁盘 I/O 繁忙，影响二进制日志（binlog）的生成和发送。
    • 源库的二进制日志（binlog）损坏或不完整，使得从库在读取和应用日志时出现错误，导致数据不一致。
    • 源库的数据库配置参数（如 binlog_format 等）设置不当，影响复制的正确性。
  3. 从库问题
    • 从库的复制线程处理能力不足，例如 CPU 资源紧张、内存不足等，无法及时处理来自多个源库的复制任务，导致复制线程间歇性中断。
    • 从库的中继日志（relay log）损坏，使得从库无法正确应用日志，造成数据不一致。
    • 从库的存储引擎问题，例如 InnoDB 存储引擎的事务处理异常，可能导致数据不一致。
  4. 复制配置问题
    • 在多源复制环境中，复制过滤规则配置错误，可能导致部分数据在某些从库上未正确复制，从而引起数据不一致。
    • 主从库之间的 GTID（全局事务标识符）配置不正确，例如 GTID_MODE 不一致，可能导致复制混乱和数据不一致。

故障排查方案

  1. 网络排查
    • 使用 ping 命令检测源库与从库之间的网络连通性和延迟情况，检查是否有丢包现象。例如：ping -c 10 <source - ip> 或 ping -c 10 <slave - ip>。
    • 通过 traceroute 命令查看网络路由路径，确定是否存在网络设备故障或路由异常。例如：traceroute <source - ip>。
    • 在源库和从库上使用 iperf 工具测试网络带宽，确保网络传输能力满足复制需求。例如：在源库执行 iperf -s，在从库执行 iperf -c <source - ip>。
  2. 源库排查
    • 查看源库的系统负载情况，包括 CPU、内存、磁盘 I/O 等。可以使用 top、free、iostat 等命令。例如，通过 top 命令查看 CPU 和内存使用情况，通过 iostat 查看磁盘 I/O 情况。
    • 检查源库的二进制日志状态，使用 SHOW BINARY LOGS 查看 binlog 文件是否完整，通过 SHOW MASTER STATUS 确认当前 binlog 位置和文件名。
    • 查看源库的数据库配置参数，特别是与复制相关的参数，如 binlog_format、server_id 等，确保参数设置正确。使用 SHOW VARIABLES LIKE '%binlog_format%' 等命令查看参数值。
  3. 从库排查
    • 同样查看从库的系统负载，检查资源是否紧张。
    • 查看从库的中继日志状态，使用 SHOW RELAYLOG EVENTS 查看中继日志内容是否正常，通过 SHOW SLAVE STATUS 确认中继日志位置和文件名。
    • 检查从库的存储引擎状态，例如对于 InnoDB 存储引擎，查看 SHOW ENGINE INNODB STATUS，检查是否有事务处理异常。
    • 查看从库的复制状态，使用 SHOW SLAVE STATUS 命令，重点关注 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 等字段，判断复制是否正常运行。
  4. 复制配置排查
    • 检查复制过滤规则，使用 SHOW SLAVE STATUS 查看 Replicate_Do_DB、Replicate_Ignore_DB 等过滤参数是否配置正确。
    • 确认主从库的 GTID 配置，使用 SHOW VARIABLES LIKE '%GTID_MODE%' 查看 GTID_MODE 是否一致，并且确保 GTID 相关参数（如 enforce_gtid_consistency）设置正确。

恢复方案

  1. 网络恢复
    • 如果是网络设备故障，联系网络管理员修复网络设备。
    • 对于网络拥塞，可以优化网络拓扑或调整网络带宽分配。
  2. 源库恢复
    • 如果源库负载过高，优化源库的业务操作，例如调整查询语句、增加数据库服务器资源等。
    • 如果 binlog 损坏，尝试从备份中恢复 binlog 文件，或者使用 MariaDB 的日志修复工具（如 mysqlbinlog 结合其他工具）尝试修复 binlog。
    • 修正源库不正确的配置参数，修改配置文件（如 my.cnf）后重启 MariaDB 服务使参数生效。
  3. 从库恢复
    • 对于资源紧张的从库，增加服务器资源（如 CPU、内存等）或优化从库的业务操作。
    • 如果中继日志损坏，删除损坏的中继日志文件（在停止复制线程后），然后重新启动复制线程，从库会自动重新获取中继日志。
    • 修复从库存储引擎的问题，例如对于 InnoDB 存储引擎的事务异常，根据 SHOW ENGINE INNODB STATUS 的提示进行处理，可能需要回滚或提交未完成的事务。
  4. 复制配置恢复
    • 修正错误的复制过滤规则，通过 CHANGE REPLICATION FILTER 语句重新设置正确的过滤参数。
    • 调整 GTID 配置，确保主从库的 GTID_MODE 一致且相关参数正确。如果需要，可以重新配置主从复制关系，使用 CHANGE MASTER TO 语句重新指定主库信息并启动复制。

验证恢复后的复制环境的正确性和稳定性

  1. 数据一致性验证
    • 选择一些关键表，在源库和从库上分别执行相同的 SELECT COUNT(*) 等统计语句，对比结果是否一致。例如：SELECT COUNT(*) FROM important_table 在源库和所有从库上执行并比较结果。
    • 对于某些有唯一索引的表，随机选取部分记录，在源库和从库上通过唯一索引查询记录的详细信息，确保数据完全一致。
    • 使用专门的数据一致性校验工具，如 pt - table - checksum（Percona Toolkit 中的工具），它可以在主从库之间进行数据校验，生成校验和并比较，以发现数据不一致的情况。
  2. 复制稳定性验证
    • 在恢复后的一段时间内（例如几个小时甚至一天），密切监控从库的复制状态，使用 SHOW SLAVE STATUS 命令定时查看 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 等字段，确保复制线程持续稳定运行，并且 Seconds_Behind_Master 保持在合理范围内（通常为 0 或非常小的值）。
    • 在源库上进行一些常规的增删改操作，观察从库是否能及时、正确地同步这些操作。例如插入一条测试数据，然后立即在从库上查询该数据是否存在。
    • 模拟生产环境的负载情况，在源库上进行一定量的并发读写操作，持续观察从库的复制情况，确保在高负载下复制依然稳定，不会出现数据不一致或复制中断的情况。