主从延迟故障场景及解决方法
- 故障场景
- 主库写入压力大，产生大量二进制日志（binlog），从库应用中继日志（relay log）速度跟不上主库生成binlog的速度。
- 从库硬件性能不足，如CPU、内存、磁盘I/O等资源受限，导致SQL线程应用日志缓慢。
- 网络延迟或不稳定，影响主从之间binlog的传输，使从库获取日志不及时。
- 解决方法
- 优化主库写入：
- 对于批量写入操作，合理控制每次写入的数据量，避免一次性写入大量数据产生过多binlog。
- 分析主库的业务逻辑，对一些不必要的写入操作进行优化，减少写入压力。
- 提升从库硬件：
- 根据从库负载情况，适当增加CPU核心数、内存容量或更换更高性能的磁盘，提升从库处理能力。
- 对从库的磁盘I/O进行优化，如使用固态硬盘（SSD）替代机械硬盘，调整磁盘参数等。
- 改善网络：
- 检查网络设备，如路由器、交换机等，确保其配置正确且运行稳定，无丢包等问题。
- 增加网络带宽，减少因带宽不足导致的日志传输延迟。
从库复制中断故障场景及解决方法
- 故障场景
- 主从之间网络连接中断，导致从库无法获取主库的binlog。
- 主库或从库上的MySQL服务异常重启，可能导致复制配置丢失或复制位点信息错乱。
- 主库上进行了一些会影响复制的操作，如删除数据库、表结构变更等，而从库未能正确应用这些操作。
- 解决方法
- 恢复网络连接：
- 检查网络设备状态，重启相关网络设备（如路由器、交换机等）尝试恢复连接。
- 确认主从服务器的防火墙配置，确保MySQL复制所需的端口（通常是3306）已开放。
- 重新配置复制：
- 如果是MySQL服务重启导致复制中断，需要在从库上重新配置复制，通过
CHANGE MASTER TO语句指定主库的地址、端口、复制用户及密码、日志文件名和位置等信息，然后使用START SLAVE启动复制。
- 例如：
CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='复制用户名',
MASTER_PASSWORD='复制密码',
MASTER_LOG_FILE='主库binlog文件名',
MASTER_LOG_POS=主库binlog位置;
START SLAVE;
- 处理主库变更：
- 对于主库上的删除数据库操作，如果从库尚未应用该操作，需要先在从库上执行相同的删除操作，然后重新配置复制。
- 对于表结构变更操作，要确保主从库上的操作一致性。如果从库复制中断，可在从库上先停止复制，手动应用相关的表结构变更语句，然后再重新启动复制。
