-
主备延迟
与数据同步有关的时间点主要包括以下三个：- 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
- 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
- 备库 B 执行完成这个事务，我们把这个时刻记为 T3。
所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
seconds_behind_master 的计算方法是这样的：
- 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
- 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。
-
主备延迟的来源
①首先，有些部署条件下，备库所在机器的性能要比主库所在的机器性能差，原因多个备库部署在同一台机器上，大量的查询会导致io资源的竞争，解决办法是配置”非双1“，redo log和binlog都只write到page cache②备库的压力大，产生的原因是大量的查询操作在备库执行，耗费了大量的cpu资源，导致同步延迟，解决办法可以使用一主多从，使用多个从库来减少备库的查询压力
③大事务，因为如果一个大的事务的DML操作导致执行时间过长，将其事务binlog发送给备库，备库也需执行那么长时间，导致主备延迟，解决办法就是尽量减少大事务，比如delete大量数据的操作，使用limit分批删除，可以防止大事务也可以减小锁的范围。
④大表的DDL，会导致主库将其DDL binlog发送给备库，备库解析中转日志，同步，后续的DML binlog发送过来，需等待DDL的MDL写锁释放，导致主备延迟。 -
主备切换的可靠性优先策略
①判断备库 B 现在的 seconds_behind_master如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步
②把主库 A 改成只读状态，即把 readonly 设置为 true
③判断备库 B 的 seconds_behind_master的值，直到这个值变成 0 为止
④把备库 B 改成可读写也就是把 readonly 设置为 false；
⑤把业务请求切换到备库 -
主备切换的可用性优先策略
不等主备数据同步，直接把连接切到备库 B，并且让备库 B 可以读写，那么系统几乎就没有不可用时间了。
出现的问题：
在双M结构下，且binlog_format=mixed，可能会导致主备数据不一致，使用 row 格式的 binlog 时，数据不一致的问题更容易发现，因为binlog row会记录字段的所有值。