概要：1、主备延迟    2、延迟原因：备压力大，大事务、并行复制能力    3、可靠性优先

双 M 结构主备切换：

一、主备延迟

    主动：软件升级、主库按计划下线，被动：机器掉电。

1、主动切换场景：“同步延迟”时间点，时间差 T3-T1：

    1）A 执行完成，写入 binlog T1;

    2） 传给备库 B，接收 binlog T2;

    3） B 执行完 T3。

备库上show slave status 显示 seconds_behind_master（备库延迟多少秒）= binlog 记录主库写入时间.- 备库取出时间字段值

2、时间不一致，不会值不准?

不会，备库连主库时， SELECT UNIX_TIMESTAMP() 获主库时间。发现不一致自动扣掉

网络正常T2-T1 非常小。延迟来源：备库接收完 binlog 和执行完时间差。

备库消费中转日志（relay log）比主库生产 binlog 慢。哪些原因导致？

二、主备延迟的来源

1、备库性能差，20 个主库在 4 台，备库集中一台（较少，对称部署常见）

       更新请求对 IOPS 压力，主、备无差别。将备库设置为“非双 1”模式。

2、更新触发大量读操作。备库抢资源，主备延迟。

追问 1：对称部署后（主备机器一样），还有延迟？

备库压力大。主库提供写能力，备库提供读能力或分析语句

主库直接影响业务，大家克制，忽视备库压力。备库上查询耗 CPU影响同步，主备延迟，解决办法：

    1）一主多从。多几个从库分担读压力（多）

    2）通过 binlog 输出到外部系统，如Hadoop提供统计类查询能力。

保证定期全量备份。从库做备份。

ps: HA 过程中被选成新主库为备库，其他为从库

追问 2：一主多从，保证备压力不超主，什么情况导致主备延迟？

大事务。主库事务完成才写binlog，再传给备库。执行 10 分钟，从库延迟 10 分钟。

    1）归档类的数据，空间快满了，一次性地删掉大量。晚上执行,收到延迟报警。分成多次删除。

    2）大表 DDL。计划内的 DDL，用 gh-ost 方案（这里，你可以再回顾下第 13 篇文章《为什么表数据删掉一半，表文件大小不变？》中的相关内容）。

追问 3：主库不做大事务，什么原因会导致主备延迟？

备库并行复制能力（具体下一篇）

三、可靠性优先策略

双 M  1 到 2（HA 系统完成）：

1. 判断备库 B seconds_behind_master（SBM）小于某个值（如 5 秒）继续下一步，否则持续重试

2. 主库 A 只读 readonly =true；直到备库 B seconds_behind_master 变0为止（耗费时间，确保SBM足够小）；

3. 备库 B可读写状态readonly = false；业务请求切到备库 B。

图 2 MySQL 可靠性优先主备切换流程  

切换流程有不可用时间。主、备库 B 都 readonly ， 完成后恢复。

主备延迟长达 30 分钟，不判断直接切换，不可用时间长达 30 分钟

数据可靠性优先策略决定。来把不可用时间几乎降为 0。

四、可用性优先策略

步骤 3调最开始执行，不等主备数据同步，直接切到备库 B，可读写，没有不可用时间，可能不一致：

主库其他表大量更新，主备延迟5 秒。自增主键 id，主、备库都 3 行数据。两条插入：

insert into t(c)  values(4); //。插入c=4 后主备切换

insert into t(c)  values(5);

图 3 是可用性优先策略，且binlog_format=mixed时的切换流程和数据结果。

图 3 可用性优先策略，且 binlog_format=mixed  

设置binlog_format=row：会记录新插入所有值，只有一行不一致。两边的主备同步的应用线程会报错 duplicate key error 并停止。 (5,4)  (5,5) 都不会被对方执行

图 4 可用性优先策略，且 binlog_format=row  

可靠性优于可用性。row 不一致更容易被发现。 mixed 或 statement 悄悄地不一致。

哪种情况可用性优先级高？

（1）库记录操作日志。不一致 binlog 修补，不会引发业务问题。

（2）库不可写导致线上业务无法执行。强行切换，事后再补。

改进办法：不依赖这类日志写入。降级，写到本地文件/临时库里面

可靠性优先，异常切换

主备延迟 30 分钟， A 掉电了切换 B 。

图 5 可靠性优先策略，主库不可用

seconds_behind_master=0 才能切换。系统不可用状态也不能切：中转日志没应用完，查询不到执行完事务，认为“数据丢失”。

随着中转日志的继续应用，数据恢复，查询到“暂时丢失数据的状态”不能接受

MySQL 高可用，可用性是依赖于主备延迟的。

小结

主备切换。主备延迟情况，改进方向。

可靠性、可用性优先策略区别。

可靠性优先（更建议）。保证数据准确，数据库服务底线。减少主备延迟，提升可用性。

思考题

备库延迟监控，执行 show slave status，采集 seconds_behind_master 值。

维护备库，延迟监控类似图 6，什么原因导致呢？怎么确认？

图 6 备库延迟

（1）大事务（大表 DDL、一个事务操作很多行）；

（2）备库长事务，比如  begin; select * from t  limit 1; 不动了.这时主库对表 t 加字段，即使表小，DDL备库被堵住

评论1

主从延迟情况:

1.主库DML并发大,从库qps高

2.从库服务器配置差或者一台服务器上几台从库(资源竞争激烈,特别是io)

3.主、从库参数配置不一样

4.大事务(DDL)

5.从库上备份

6.表上无主键(主库用索引update,备库回放只能全表扫描,可调整slave_rows_search_algorithms适当优化)

7.设置延迟备库

8.备库空间不足

看曲线,是从库大事务,或大表无主键，时间增长,second_behind_master也有规律增长

评论2

1,备库备份产生MDL锁，复制线程被堵塞，kill备份线程畅快。备份产生非共享锁不是短时间就释放？为什么堵的时间那么长？像是死锁

2，归档程序用共享存储，占用导致，同样连接该存储上数据库写瓶颈，写中继日志慢（没滞留），应用日志线程正常。产生备库延迟。当时第一反应是网络带宽被打满了，确认没问题。看存储IOPS。定位批量写入。

评论3

大事务，second_behind_master当前系统时间戳减sql_thread执行binglog event时间戳

SBM判断主从同步有严重问题，从库不会马上知道和主库连接不通，从库有salve_net_timeout=x秒 （设小，检测与主库通讯）。或用pt-hearbeat检测主从延迟。

mysql主从复制，连接（重连）时从库告诉主库信息，之后主库主动（根据要求发日志binlog ）靠备库轮询，有时间差