主备库同步的时候, 毕竟是在两台机器上的,延迟问题肯定是有的。
主备同步延迟
- 主库提交日志了后, 主库是后台线程读取日志发送给从库的,如果主库压力大, 后台同步线程可能会延迟一点读取到日志
- 发送日志会有网络延迟, 但是现在主备库都是在公司的内部局域网中,这个延迟可以忽略不计
- 备库接收到日志后,消费这些日志信息执行会耗时。
备库机器性能差
有些公司可能备库真的只是备库, 不会转正的,所以选择一个性能差的机器做备库, 或者一个机器上装上个四五个备库, 这样自然会导致备库的延迟
表上没有主键
主库使用内部rowId作为主键索引, 但是这个rowId不会同步到从库的。 从库只能使用全表扫描来同步,
导致延迟。
备库业务频繁
按道理来说,主库才是真正的业务大头, 备库只要同步下bin log中的操作, 不用进行读数据操作,所以不会出现业务频繁的, 但是现实往往会打脸。
比如有些公司为了不影响主业务,把一些不重要的后台统计吗运营等等业务,放在备库来执行, 又由于是备库,开发人员在使用的时候就没有主库一样的小心翼翼, 导致备库业务量飙升, 备库压力大, 导致延迟加大。
解决办法: 可以一主多从库啊。 可以用bin log 接入到外部Hadoop系统, 运营业务可以使用Hadoop来做。
大事务导致延迟
一个事务在主库上就会执行10分钟, 那么从库上也会执行10分钟, 这就有10分钟延迟了。
比如大批量的数据删除操作, 和大表的DDL语句都是大事务。
主备切换的可靠性优先策略
- 检查从库和主库的延迟, 检查方式是看从库的 接收的binlog中最新事务的时间和本机当前时间差, 延迟小于5秒的时候,进行下步操作, 大于五秒的时候,继续检查
- 延迟小于5秒,把主库设置成只读,
- 备库继续判断延迟,直到延迟为0 。 把备库改为可写状态
- 把业务切换到备库
这整个流程中, 会有5秒左右的时间两个库都是只读状态,业务不可用。 但是这样切换过来后的数据库不会出现数据不一致的问题。
这个方式是在主备库完全一致后才会切换主备的。
主备切换的可用性优先策略
- 先把备库改成可写的。
- 把业务切换到备库
- 再让之前的主库把日志慢慢同步过来保持一致
这个方式倒是会使得系统是都是可用的, 但是他会出现数据不一致的问题的。 采用这个方式需要考虑清楚业务是否能够忍受可能的不一致情况。
两种策略的优劣
可靠性是会保证数据一致性, 但是现实中情况会很复杂, 比如主库挂了, 这个时候还是用可靠性策略就不合适了。
可用性策略的优点正如名称一样, 它不会使得业务系统出现不可用的情况, 往往线上采用的也是比较多, 如果我们能保证主备延迟足够小,采用这种策略就算出现不一致了, 从bin log中订正数据的工作量也不会有多少。