面试题：MariaDB 基于 GTID 的 MySQL 复制 - 故障处理

Question

在 MariaDB 基于 GTID 的 MySQL 复制过程中，如果从库出现复制延迟或中断，可能有哪些原因，你会如何进行排查和解决？

Answer 1

可能原因

1. 网络问题：
   • 主从服务器之间网络不稳定或带宽不足，导致数据传输延迟或中断。
   • 网络设备（如路由器、交换机）配置错误或故障。
2. 主库负载过高：
   • 主库上有大量的写入操作，导致主库处理事务速度慢，从库接收日志延迟。
   • 主库硬件资源（如 CPU、内存、磁盘 I/O）不足，影响事务处理性能。
3. 从库负载过高：
   • 从库上有大量查询操作，占用资源，导致复制线程处理延迟。
   • 从库硬件资源不足，无法及时处理接收到的主库日志。
4. 复制配置问题：
   • 主从库之间的 GTID 配置不一致，如主库开启 GTID，从库未正确配置或配置错误。
   • 复制用户权限不足，无法执行必要的操作。
5. 数据不一致问题：
   • 主从库数据本身存在不一致，导致复制过程中出现错误，从而中断或延迟。
   • 从库上手动执行了与主库不一致的操作（如 DDL 操作）。
6. 日志相关问题：
   • 主库二进制日志损坏或丢失部分日志，导致从库无法正常应用。
   • 从库中继日志损坏，影响复制。

排查步骤

1. 网络检查：
   • 使用 ping 命令检查主从服务器之间的网络连通性，查看是否有丢包或延迟过高的情况。
   • 使用 traceroute 命令检查网络路由是否正常，查看是否存在路由异常。
   • 检查网络设备（如路由器、交换机）的配置和状态，确保没有端口错误或带宽限制。
2. 主库负载检查：
   • 使用 top 命令查看主库服务器的 CPU、内存使用情况，判断是否资源不足。
   • 使用 iostat 命令查看磁盘 I/O 情况，看是否存在磁盘瓶颈。
   • 查看主库的 SHOW PROCESSLIST，分析是否有大量长时间运行的写入事务。
3. 从库负载检查：
   • 同样使用 top 和 iostat 命令检查从库服务器的资源使用情况。
   • 查看从库的 SHOW PROCESSLIST，分析是否有大量查询操作占用资源。
4. 复制配置检查：
   • 检查主从库的 GTID 配置，确保主库 gtid_mode=ON 且 enforce_gtid_consistency=ON，从库也正确配置了相关 GTID 参数。
   • 检查复制用户权限，确保其具有 REPLICATION SLAVE 等必要权限。
5. 数据一致性检查：
   • 使用工具（如 pt-table-checksum）来检查主从库数据的一致性。
   • 查看从库的错误日志，检查是否有因数据不一致导致的复制错误。
6. 日志检查：
   • 检查主库二进制日志文件的完整性，查看 SHOW BINARY LOGS 输出，确保日志文件没有损坏。
   • 检查从库中继日志，查看 SHOW RELAYLOG EVENTS，确保中继日志正常。

解决方法

1. 网络问题解决：
   • 如果是网络不稳定，联系网络管理员排查网络故障，如更换网线、调整网络设备配置等。
   • 如果带宽不足，考虑增加网络带宽。
2. 主库负载问题解决：
   • 如果 CPU 或内存不足，考虑升级硬件配置，或优化主库上的查询和写入操作，减少不必要的负载。
   • 如果磁盘 I/O 瓶颈，可考虑更换高性能磁盘（如 SSD），或优化数据库存储结构，减少磁盘读写。
3. 从库负载问题解决：
   • 优化从库上的查询，添加合适的索引，减少查询对资源的占用。
   • 若资源不足，同样可考虑升级硬件配置。
4. 复制配置问题解决：
   • 修正 GTID 配置错误，确保主从库 GTID 配置一致并正确。
   • 重新授予复制用户正确的权限。
5. 数据不一致问题解决：
   • 根据数据不一致检查工具的结果，手动修复数据，或使用工具（如 pt-table-sync）来同步数据。
   • 避免在从库上手动执行与主库不一致的操作，若已执行，需评估影响并进行修复。
6. 日志问题解决：
   • 如果主库二进制日志损坏，尝试从备份中恢复损坏部分的日志，或重新配置复制。
   • 如果从库中继日志损坏，可删除损坏的中继日志，让从库重新获取日志并应用。