MYSQL的主备同步延迟问题

主备库同步的时候， 毕竟是在两台机器上的，延迟问题肯定是有的。

主备同步延迟

1. 主库提交日志了后， 主库是后台线程读取日志发送给从库的，如果主库压力大， 后台同步线程可能会延迟一点读取到日志
2. 发送日志会有网络延迟， 但是现在主备库都是在公司的内部局域网中，这个延迟可以忽略不计
3. 备库接收到日志后，消费这些日志信息执行会耗时。

备库机器性能差

有些公司可能备库真的只是备库， 不会转正的，所以选择一个性能差的机器做备库， 或者一个机器上装上个四五个备库， 这样自然会导致备库的延迟

表上没有主键

主库使用内部rowId作为主键索引， 但是这个rowId不会同步到从库的。 从库只能使用全表扫描来同步，
导致延迟。

备库业务频繁

按道理来说，主库才是真正的业务大头， 备库只要同步下bin log中的操作， 不用进行读数据操作，所以不会出现业务频繁的， 但是现实往往会打脸。

比如有些公司为了不影响主业务，把一些不重要的后台统计吗运营等等业务，放在备库来执行， 又由于是备库，开发人员在使用的时候就没有主库一样的小心翼翼， 导致备库业务量飙升， 备库压力大， 导致延迟加大。

解决办法： 可以一主多从库啊。 可以用bin log 接入到外部Hadoop系统， 运营业务可以使用Hadoop来做。

大事务导致延迟

一个事务在主库上就会执行10分钟， 那么从库上也会执行10分钟， 这就有10分钟延迟了。

比如大批量的数据删除操作， 和大表的DDL语句都是大事务。

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

1. 检查从库和主库的延迟， 检查方式是看从库的 接收的binlog中最新事务的时间和本机当前时间差， 延迟小于5秒的时候，进行下步操作， 大于五秒的时候，继续检查
2. 延迟小于5秒，把主库设置成只读，
3. 备库继续判断延迟，直到延迟为0 。 把备库改为可写状态
4. 把业务切换到备库

这整个流程中， 会有5秒左右的时间两个库都是只读状态，业务不可用。 但是这样切换过来后的数据库不会出现数据不一致的问题。

这个方式是在主备库完全一致后才会切换主备的。

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

1. 先把备库改成可写的。
2. 把业务切换到备库
3. 再让之前的主库把日志慢慢同步过来保持一致

这个方式倒是会使得系统是都是可用的， 但是他会出现数据不一致的问题的。 采用这个方式需要考虑清楚业务是否能够忍受可能的不一致情况。

两种策略的优劣

可靠性是会保证数据一致性， 但是现实中情况会很复杂， 比如主库挂了， 这个时候还是用可靠性策略就不合适了。

可用性策略的优点正如名称一样， 它不会使得业务系统出现不可用的情况， 往往线上采用的也是比较多， 如果我们能保证主备延迟足够小，采用这种策略就算出现不一致了， 从bin log中订正数据的工作量也不会有多少。