一、在master实例上执行了大事务

1、概述

所谓大事务，就是指一次执行数万行记录的更新以及对大表的DDL操作。简单说，就是需要执行很长时间的事务。

2、解决方案

针对一次执行数万行记录的更新，可以采用化大事务为小事务，分批更新数据的方式解决。

针对对大表的DDL操作，我们可以使用pt-online-schema-change工具来完成对大表的DDL。

注：使用 pt-online-schema-change 在线修改表结构

　

二、网络延迟

1、概述

其实如果是内网传输，网络延迟基本可以忽略不计，当然如果是特殊情况，比如在master上对一个具有数千万行的数据表进行了一次全表更新，并且二进制格式采用的又是完整的row格式，这时就可能产生好几个G的二进制日志。

这时，由于要传输好几个G的日志，就有可能出现网络延迟带来的主从复制延迟的情况，当然这也是比较极端的情况。归根结底，还是由于大事务的原因。

2、解决方案

既然归根结底还是由于大事务的原因，因此我们还是要避免大事务的产生。

　

三、在master下有太多slave

1、概述

在平时还好，但如果是大促时候，就可能导致由于二进制日志，把master网卡带宽占满的情况。

2、解决方案

减少一个master下slave的数量，尽量控制在5个以内。

　

四、主上多线程写入，从上单线程恢复

1、概述

在实际应用中，通常都是多个线程同时对master进行写入，但是slave上只有一个SQL线程通过relay log来同步master的数据，这必然会造成一定程度上的主从同步延迟。

2、解决方案

（1）方式一：使用5.7版本之后的多线程复制。

所谓多线程复制，就是在slave上使用多个SQL线程对relay log进行数据恢复。

注：虽然5.6版本已经提供了多线程复制，但5.6版本中的多线程复制时针对数据库级的，如果我们所有的写都集中在同一个数据库，这时采用5.6版本的多线程复制可能并不会带来太大的影响。在5.7版本之后，MySQL对多线程复制进行了优化，可以针对数据表级进行多线程复制。

（2）方式二：使用5.7版本之后的MGR复制方式

MGR复制是一种多写复制集群，这种方式比较类似于percona PXC集群。

关于MGR复制方式，详见文章 MGR复制