MySQL45讲之保证高可用 - flowers

前言

本文主要介绍 MySQL 主备延迟，延迟产生的原因和主备切换策略。

主备延迟

主备同步过程中时间点主要有三个：

1. 主库A执行完成一个事务，写入binlog，我们把这个时刻记为T1;

2. 之后传给备库B，我们把备库B接收完这个binlog的时刻记为T2;

3. 备库B执行完成这个事务，我们把这个时刻记为T3。

所谓主备延迟，指的就是同一个事务下，T3-T1 的时间差值。

主备延迟的计算，可以在备库下，通过 show slave status 命令查看，返回的结果中 seconds_behind_master 代表的就是主备延迟，单位是秒。它会等于（备机执行 binlog 时间戳 - binlog 记录的主机执行时间戳）。

一般在网络正常的情况下，备机接收主机发送的 binlog 很快，即 T2-T1 很小，可以忽略不计。主备延迟的主要来自于 T3-T2，这个时间差值代表备机执行中继日志（relay log）的速度比主机产生 binlog 日志的速度慢多少。

此外，你心里可能还会想主备机器系统时间不一致是否会影响主备延迟？
答案是不会的。因为在主备机器连接上之后，备机会获取主机的系统时间，然后和本机系统时间比较，计算出差值，在后面计算的时候都会带上这个差值

产生原因

1. 备机的性能比主机差

目前，这种部署少了，因为考虑到会进行主备切换，所以一般采用对称部署，即主备机采用一样的规格。

2. 备机压力大

主机用来完成写操作，而备机可能用于完成一些读操作，或者后台运营做一些数据分析的工作。备机的压力不比主机小，从而导致备机的同步延迟。

解决方案：

一主多从，多个从机分担查询压力
2、对于数据分析场景，可以将 binlog 同步到外部系统，像 hadoop。

3. 大事务

即便保证主备机压力基本一致，但大事务情况下，主备机都要耗费相近的执行时间，从而导致备机的同步延迟。所以，DBA 往往会叮嘱开发不要执行大事务。就算一定要执行，也要将大事务分割成多个小事务来执行。

4. 大表DDL

大表DDL会占用很多的 CPU 和 IO 资源，很容易造成主备延迟。所以，要比较安全的操作，建议采用 gh-ost 进行。

开发在线上执行 SQL 时一定要注意，不能执行大事务或者大表DDL这种耗时操作，尤其是比较重要的服务，否则会造成主备延迟，影响业务。

主备切换策略

1. 可靠性优先策略

切换步骤：

1. 判断备库B现在的seconds_behind_master，如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；

2. 把主库A改成只读状态，即把readonly设置为true；

3. 判断备库B的seconds_behind_master的值，直到这个值变成0为止；

4. 把备库B改成可读写状态，也就是把readonly 设置为false；

5. 把业务请求切到备库B。

可靠性优先的缺点在于主备机存在一段时间的不可用状态，不可用的时间长短取决于步骤 3，直到步骤 5 执行完成后才恢复。

2. 可用性优先策略

为了保证可用性优先，会先执行步骤 4、5，使得不可用时间为 0 。但是这可能会造成主备机的数据不一致。

参考

• [1] MySQL是怎么保证高可用的