mysql之主备延迟

前言

之前的文章介绍了mysql 的主备原理，今天我们将继续介绍主备存在的延迟问题。

主备延迟的原因

要知道主备延迟的原因，首先得知道大概的主备数据同步过程。主备数据的同步过程大致有三步

1.A数据库写入一个事务，然后将日志写入到binlog中，这个时刻为T1

2.A数据库将日志发送到B数据库，B数据库完整的接收到整个binlog日志，这个时刻记为T2

3.B数据库将接收到的binlog日志写入自己本地的binlog日志中，然后执行对应的日志事务，这个时刻记为T3

上面的A数据库为主库，B数据库为备库，主备延迟的时间差为T3-T1，但是如果不考虑网络波动的话，数据库之间传输日志是非常快的，也就是T2-T1的结果是非常小的。所以，我们在不考虑网络波动的情况下，可以将主备延迟视为T3-T2.

增加延迟时间的情况

由上可知，数据库的主要延迟就是取决于备库执行binlog日志对应事务的时间。那么增加延迟时间的本质就是增加备库处理日志的速度，而增加备库处理日志速度的情况大致有三种

1.备库所在服务器配置比较差

2.将大量查询语句放在备库

3.大事务的产生。如果主库执行了一个长达10分钟的事务，那么在主库和备库配置相差不大的情况下，备库处理该事务对应日志的时间，也得接近10分钟

主备切换策略

由于主备之间存在延迟，不同的情况下，延迟的时间也是不同的。因此对应不同的情况，主备切换有着不同的策略。

1.可靠性优先策略
在可靠性优先策略下，主备切换大致是这样的步骤
（1）判断主备延迟是否小于n（自己设置的值）秒，如果大于，则不断重试，小于则进行下一步。
（2）将主库设置为只读状态
（3）判断主备延迟时间，直到延迟时间为0
（4）将备库设置为可读可写的状态
（5）将业务请求切换到备库

2.可用性策略
可用性策略其实就是没有可靠性策略的1和3，也就是不会判断延迟时间和等待延迟数据同步，直接进行主备切换。这种操作虽然避免了数据库出现不可用的情况，但是会出现数据不一致的情况。

假如主备同步数据的时候，binlog日志使用的是mixed格式（这个之前介绍主备的时候，有详细的介绍，这里不再赘述），这个时候就会出现数据不一致的情况。

假设你在主库插入一条数据

insert (id,c) values( 4)

但是因为主备之间有延迟，你直接切换，这个日志还没被处理。这个时候，备库执行了这么一条sql，那么可能导致这个新插入的sql，比之前主库插入的sql先执行。

insert (id,c) values( 5)

原本你插入的应该是（4，4），（5，5），但是因为主备有延迟，你直接切换主备，导致你插入的数据就会变成（4，5），（5，4），这样就会出现数据不一致的情况。

上面的情况，我们可以通过设置binlog 的日志格式为row解决。当binlog格式设置为row的时候，binlog会存储整行数据。这个时候，你插入数据（4，5）的时候，会发现和日志记录的数据（4，4）不一致，则不会插入。并且线程会报错，这个时候你就可以发现数据不一致的情况。

总结

大多数时候，数据的可靠性要比速度重要的多。所以一般情况下，我们还是使用可靠性策略。但是事无绝对，有的情况下，还是可以使用可用性策略的。比如，你同步的是一个日志数据库，且业务数据依赖这个日志数据库，并且不能忍受这个数据库有不可用的时间，这个时候就可以使用可用性策略，毕竟日志即使丢失，也能通过binlog找回。