主从延迟调优思路详解

针对主从延迟问题，优化思路主要包括以下几个方面：分析延迟原因，确定延迟来源；优化数据传输效率，提升主从之间的通信速度；调整系统参数，优化数据处理能力；实施监控和预警机制，实时掌握系统运行状况，及时发现并解决延迟问题，通过以上措施，可有效提升系统性能，降低主从延迟，提高系统的稳定性和响应速度。

greatsql社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。1、什么是主从延迟？本质上是从库的回放速度赶不上主库，回放阶段的延迟。

2、主从延迟常见的原因有哪些？

1. 大事务导致从库回放时间过长，从而引起主从延迟。
2. 主库写入过于频繁，从库无法及时回放。
3. 参数配置不合理。
4. 主从硬件存在差异。
5. 网络延迟。
6. 表没有主键或索引，导致大量频繁的更新操作。
7. 一些读写分离的架构中，从库承受较大的压力。

3、解决主从延迟的方法有哪些？

1. 将大事务拆分成小事务。
2. 启用并行复制。
3. 升级从库硬件。
4. 尽量确保所有表都有主键。

4、什么是并行复制，参数有哪些？ 回顾MySQL并行复制的发展历程：

MySQL5.6 基于数据库级别的并行复制，配置为 slave-parallel-type=DATABASE（不同库的事务没有锁冲突）。

MySQL5.7 基于group commit的并行复制，配置为 slave-parallel-type=LOGICAL_CLOCK，即Commit-Parent-Based模式（同一组的事务[last-commit相同]没有锁冲突。同一组内肯定没有冲突，否则无法成为同一组）。上述是从库的配置，并行复制依赖于主库的组提交（注意区分组复制）。

代码语言：text

复制

greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name                           | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay          | 0     |
| binlog_group_commit_sync_no_delay_count | 0     |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)

binlog_group_commit_sync_delay：等待多少时间后才进行组提交。 binlog_group_commit_sync_no_delay_count：等待多少个事务后才进行组提交。