mysql复制延迟如何处理
一、复制延迟的原因
- 主库增删改并发大
- 大表在做DDL
- 从库备份导致延迟
- 大事务
- 从库机器配置差
二、怎样判断延迟
使用 SHOW SLAVE STATUS
命令
- Seconds_Behind_Master:表示从库落后主库的秒数(若为 NULL,可能复制线程已停止)
- 对比位点
字段名 | 含义说明 |
---|---|
Master_Log_File | 从库的 IO 线程正在读取的主库 binlog 文件名 |
Read_Master_Log_Pos | 从库的 IO 线程已读取到的主库 binlog 位点 |
Relay_Master_Log_File | 从库的 SQL 线程正在执行的事务对应的主库 binlog 文件名 |
Exec_Master_Log_Pos | 从库的 SQL 线程已执行到的主库 binlog 位点 |
- 对比GTID
字段名 | 说明 |
---|---|
Auto_Position | 为 1 表示启用了 GTID 复制 |
Retrieved_Gtid_Set | 从库已接收的所有事务的 GTID 集合 |
Executed_Gtid_Set | 从库已执行的所有事务的 GTID 集合 |
无延迟:
Retrieved_Gtid_Set == Executed_Gtid_Set
,表示从库已全部执行完主库传来的事务。
有延迟:
Executed_Gtid_Set
是 Retrieved_Gtid_Set
的真子集,说明还有事务未执行完。
三、主从延迟处理方法
1、开启多线程
2、调整一些MySQL的参数
以下是对 innodb_flush_log_at_trx_commit
和 sync_binlog
两个参数的表格形式介绍,以及在主从因 IO 延迟时的建议:
参数名称 | 允许值 | 描述 | 建议(主从 IO 延迟场景) |
---|---|---|---|
innodb_flush_log_at_trx_commit | 0, 1, 2 | 控制 InnoDB Redo Log 的写盘策略: | 建议设置为 2(性能与安全的折中),可减少主从 IO 延迟 。 |
sync_binlog | 0, 1, N | 控制 Binlog 的同步策略: | 建议设置为 1000(或类似值),可减少主从 IO 延迟,但需接受一定数据丢失风险 。 |
3、 调整从库配置
4、避免大事务
5、使用PT工具执行耗时较长的DDL
6、调整架构