一、主备延迟：
1、数据同步有关的时间点：
①、主库A执行完成一个事务，写入binlog，把这个时刻记为T1;
②、之后传给备库B，把备库B接收完这个binlog的时刻记为T2;
③、备库B执行完成这个事务，我们把这个时刻记为T3。
2、主备延迟的概念：
同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。可以在备库上执行show slave status命令，它的返回结果里面会显示seconds_behind_master（时间精度是秒），用于表示当前备库延迟了多少秒。
3、主备库机器的系统时间设置不一致对主备延迟的值是否有影响？
没有影响。因为备库连接到主库的时候，会通过执行SELECT UNIX_TIMESTAMP()函数来获得当前主库的系统时间。如果此时发现主库的系统时间与自己不一致，备库在执行seconds_behind_master计算的时候会自动扣掉这个差值。
在网络正常的时候，日志从主库传给备库所需的时间是很短的，即T2-T1的值是非常小的。也就是说，网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产binlog的速度要慢。
二、主备延迟的来源：
1、备库所在机器的性能要比主库所在的机器性能差。
比如说把20个主库放在4台机器上，而把备库集中在一台机器上。要注意更新请求对IOPS的压力，在主库和备库上是无差别的。所以，做这种部署时，一般都会将备库设置为“非双1”的模式。但实际上，更新过程中也会触发大量的读操作。所以，当备库主机上的多个备库都在争抢资源的时候，就可能会导致主备延迟了。
处理方法：主备库选用相同规格的机器，并且做对称部署。
2、做了对称部署以后，还会有延迟的原因：备库的压力大。
由于主库既然提供了写能力，那么备库可以提供一些读能力。或者一些运营后台需要的分析语句，不能影响正常业务，所以只能在备库上跑。由于主库直接影响业务，所以使用起来会比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟。
处理方法：
①、一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。（主要选择，因为作为数据库系统，还必须保证有定期全量备份的能力。而从库就很适合用来做备份。）
②、通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
3、采用了一主多从，保证备库的压力不会超过主库，还会导致主备延迟的原因：大事务。
主库上必须等事务执行完成才会写入binlog，再传给备库。所以，如果一个主库上的语句执行10分钟，那这个事务很可能就会导致从库延迟10分钟。
典型的大事务场景：
①、一次性地用delete语句删除太多数据。
②、大表DDL。
处理方法：
对于“一次性地用delete语句删除太多数据”，需要控制每个事务删除的数据量，分成多次删除。
对于“大表DDL”，计划内的DDL，建议使用gh-ost方案。
4、如果主库上不做大事务，还有导致主备延迟的原因：库的并行复制能力。
三、主备切换时采用的策略：
1、可靠性优先策略：
在双M结构下，从状态1到状态2切换的详细过程：
①、判断备库B现在的seconds_behind_master（简写为SBM），如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；
②、把主库A改成只读状态，即把readonly设置为true；
③、判断备库B的seconds_behind_master的值，直到这个值变成0为止；
④、把备库B改成可读写状态，也就是把readonly 设置为false；
⑤、把业务请求切到备库B。
注意：
①、这个切换流程中是有不可用时间的。因为在步骤2之后，主库A和备库B都处于readonly状态，也就是说这时系统处于不可写状态，直到步骤5完成后才能恢复。
②、在这个不可用状态中，比较耗费时间的是步骤3，可能需要耗费好几秒的时间。这也是为什么需要在步骤1先做判断，确保seconds_behind_master的值足够小。
2、可用性优先策略：
假设有表T：
mysql> CREATE TABLE `t` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`c` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(c) values(1),(2),(3);
假设要继续在表t上执行两条插入语句的命令：
insert into t(c) values(4);
insert into t(c) values(5);
假设现在主库上其他的数据表有大量的更新，导致主备延迟达到5秒。在插入一条c=4的语句后，发起了主备切换;
当binlog_format=mixed时，切换流程和数据结果如下：
切换流程：
①、步骤2中，主库A执行完insert语句，插入了一行数据（4,4），之后开始进行主备切换。
②、步骤3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用“插入c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。
③、步骤4中，备库B插入了一行数据（4,5），并且把这个binlog发给主库A。
④、步骤5中，备库B执行“插入c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库B执行的“插入c=5”这个语句，传到主库A，就插入了一行新数据（5,5）。
这导致了主库A和备库B上出现了两行不一致的数据。
当binlog_format=row时，切换流程和数据结果如下：
对比binlog_format=mixed和binlog_format=row时的切换流程和数据结果，可以看出：
①、使用row格式的binlog时，数据不一致的问题更容易被发现。而使用mixed或者statement格式的binlog时，数据很可能悄悄地就不一致了。如果你过了很久才发现数据不一致的问题，很可能这时的数据不一致已经不可查，或者连带造成了更多的数据逻辑不一致。
②、主备切换的可用性优先策略会导致数据不一致。因此，大多数情况下，都建议使用可靠性优先策略。毕竟对数据服务来说的话，数据的可靠性一般还是要优于可用性的。
