目录

• • 主备切换
  • 主备延迟的原因
  • 可靠性优先策略的主备切换流程
  • 可用性优先策略的主备切换流程

主备切换

主备切换分为主动运维与被动操作。

软件升级、主库所在机器按计划下线为主动运维。

主库所在机器掉电为被动操作。

同步延迟

1、主库A执行完一个事务，写入binlog，时刻T1

2、传给备库B，备库B接受完这个binlog，时刻T2；

3、备库B执行完这个事务，时刻T3；

同一个事务，在备库执行完成的时间和主库执行完成的时间之差为T3-T1，又称主备延迟。

在备库执行show slave status命令会显示seconds_behind_master，表示备库延迟了多少秒。

主备库机器系统时间设置不一样并不会导致主备延迟的值不准。

在网络正常的时候，日志从主库传给备库的时间T2-T1是很短的。也就是说网络正常时，主备延迟的主要来源是备库接受完binlog和执行这个事务之间的时间差。

主备延迟最直接的表现就是：备库消费中转日志(relay log)的速度，比主库生产binlog的速度慢。

主备延迟的原因

1、备库所在机器的性能可能比主库所在的机器性能差

2、备库压力大。（主库提供写能力，备库提供读能力）

由于主库直接影响业务，使用起来比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟。

这种情况可以这么解决：

1、一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力2、通过binlog输出到外部系统，让外部系统提供统计查询的能力

3、大事务情况

由于主库必须等事务执行完才会写入binlog，再传给备库。

如果一个主库上的语句执行10分钟，那么这个事务很可能会导致从库延迟10分钟。

典型大事务场景

a、一次性删掉大量历史数据。需要控制每个事务删除的数据量，分成多次删除

b、大表DDL

4、备库并行复制能力差

可靠性优先策略的主备切换流程

在M-M结构下，状态1切换到状态2流程如下：

1、判断备库B现在的seconds_behind_master，如果小于某个值(比如5s)继续下一步，否则继续重试这一步

2、把主库A改成只读状态，(readonly设置为true)

3、判断备库B的seconds_behind_master，直到这个值变为0

4、把备库改成可读写状态，(readonly设置为false)

5、把业务请求切换到备库B

step2之后，主库A和备库B都处于readonly状态，此时系统处于不可写状态，直到step5才能恢复。step3比较耗时。

可用性优先策略的主备切换流程

如果强行把上面的step4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎没有不可用时间。

这个切换流程，称为可用性优先流程，不过这个切换的代价，就是可能出现数据不一致的情况。

结论如下：

1、使用row格式的binlog时，数据不一致的问题更容易被发现。使用mixed或者statement格式的binlog时，数据很可能就不一致了。

2、主备切换的可用性优先策略会导致数据不一致，所以一般情况下使用可靠性优先策略。

下面介绍一个使用可用性优先策略的情形：

• 有一个库的作用是记录操作日志。如果数据不一致可以通过binlog来修补，而这个短暂的不一致也不会引发业务问题。

• 同时，业务系统依赖于这个日志写入逻辑，如果这个库不可写，会导致线上的业务操作无法执行。

如果使用可靠性优先的思路，只能等待备库慢慢应用中转日志，在备库应用完中转日志且切换成读写状态之前，数据库是处于不可用的状态。 这时也不能直接切换到备库B，然后保持B库只读。

所以此时就需要用到可用性优先策略。

Mysql的高可用性，依赖于主备延迟。主备延迟的时间越小，出现故障的时候，服务需要恢复的时间就越短，可用性就越高