MySQL 主从复制高延迟

 

 

主从高延迟:

1. 网络延迟
2. max_allowed_packet
3. auto_increment_increment           auto_increment_offset
4. sync_binlog=1       innodb_flush_log_at_trx_commit
5. 事务长时间没有提交   大表的DDL
6. 复制错误
7. 串行执行大事务
   假如master串行执行一个大事务需要30分钟，那么slave应用这个事务也大约要30分钟，从master提交的那一刻开始，slave的延迟就是30分钟，更极端一点，由于binlog的记录时间点是在事务提交时，如果这个大事务的日志量很大，比如要传输10多分钟，那么很可能延迟要达到40分钟左右。而且更严重的是，这种延迟具有滚雪球的特性，从延迟开始，很容易导致后续加剧延迟。

 

 

优化方案:

1. 不要在MySQL中使用大事务(对应串行执行大事务)
2. 从产生Binlog的master上考虑，可以在master上应用group commit的功能，并设置参数binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，前者表示延迟多少秒才提交事务，后者表示要堆积多少个事务之后再提交。这样一来，事务的产生速度降低，slave的SQL线程相对就得到缓解。
   
   
3. 最后从架构上考虑。主从延迟是因为slave跟不上master的速度，那么可以考虑对master进行节流控制，让master的性能下降，从而变相提高slave的能力。这种方法肯定是没人用的，但确实是一种方法，提供了一种思路，比如slave使用性能比master更好的硬件。另一种比较可取的方式是加多个中间slave层(也就是master->slaves->slaves)，让多个中间slave层专注于复制(也可作为非业务的他用，比如用于备份)。
   
   
4. 设置row格式的binlog比statement好,不需要额外执行语句,直接修改数据
5. master设置保证数据一致性的日志刷盘规则
   

   sync_binlog=1
   innodb_flush_log_at_trx_commit=1

    

6. slave关闭binlog,设置性能优于数据一致性的binlog
7. slave 的隔离级别加大,使得slave的锁粒度放大,不会轻易锁表(多线程避免使用)
8. 高速磁盘,设计好分库分表结构