主备延迟
主备切换是很正常的操作,比如服务下线,断电,软件升级等等,首先我们先了解另外一个概念就是同步延迟,与数据同步的三个时间点如下主库A上执行的一个事务,写入binlog,这个时刻是T1
备库B接收完成这个binlog的时刻是T2
在备库上执行完这个事务时刻就是T3
show slave statusseconds_behind_master// 表示备库的延迟时间,表示延迟了多少秒
seconds_behind_master计算方式如下
每个事物的binlog日志都会有一个时间
在备库上获取binlog日志的时候,获取到这个时间,计算他和当前系统上的时间差
主备延迟的来源
有些情况是主库部署的机器性能比备库的机器好,比如,有些公司会把主库部署在多个机器上,而把备库部署在一条机器,这样就会导致备库的主机上的多个备库会抢夺资源,导致主备延迟 但是实际上,很少有公司那样做,而是使用的主备可以随时切换,因此部署的机器的性能都一样且是对称部署但是为什么这样的部署,也会出现主备延迟呢
正常情况下主库设置读写操作,而备库设置只读操作,由于主库的操作可能会影响生产环境的业务,因此大多数消耗资源的操作就会在备库上执行,因此就会导致主备延迟,当然我们也可以使用下面策略使用一主多从策略,使用多个从库分担读的能力
输出binlog日志到外部系统如Hadoop系统,让外部系统提供查询统计这类查询
如果按照一主多从的部署,还会有其他情况引起主备延迟吗
其实大事务也是可能引起延迟的,比如我们在主库上执行了一个大事务,这个事务执行了10分钟,就会导致备库延迟10分钟,因此有时候我们再使用delete删除整张表的数据,就会导致报警,此时我们就必须采用多次删除. 由于存在主备延迟的情况,因此有会有相应的策略可靠优先策略
判断备库上的seconds_behind_master的时间差是否小于某个值(例如5秒),如果不小于,就重复判断直到小于
把主库设置成只读
再判断备库上的seconds_behind_master的值为0
在把备库设置成读写
把业务切换到备库
可用性优先策略
我们是不是可以把步骤4,5提前到最开始,直接切换主备库,这样就不会出现不可用的情况了,但是我们会发现可能会导致数据不一致的情况我们可以举个例子如下
mysql> CREATE TABLE `t` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `c` int(11) unsigned DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;insert into t(c) values(1),(2),(3);
假设主库上的其他表有大量的更新操作,此时的备库延迟是5秒,在主库上执行插入c=4的语句,然后进行主备切换
使用可用性优先策略,且binlog_format=mixed,切换流程如下
在步骤2中主库上执行完c=4后,进行主备切换
步骤3,由于有主备延迟的存在5秒,此时备库还没有进行插入c=4的中转日志,且备库已经开始接受客户端的命令c=5的sql
在步骤4中,备库中接受了c=5的命令,且生成的binlog传给了主库,且也
在步骤5中,主库插入了记录(5,5),且在备库上插入了记录(5,4)
但是此时我们假设binlog_format=row,会记录插入的所有字段,做一只有一行数据不一致,主备库上会发生主键冲突而停止,
可以看到如果binlog_format=row是更容易发现,但是如果是mixed或statement就不容易发现,当你发现的时候,已经没有办法查询了,也有可能导致更多的数据不一致
可用性优先策略可能会导致数据不一致性,因此建议使用可靠性优先策略,数据的一致性比较高.
那些场景可用性优先策略适合呢
比如下面场景就比较适合有一个库专门是用来记录操作日志,这个时候数据不一致可以用binlog日志修复,短暂的数据不一致不影响业务流程
同时,业务系统依赖日志的写入逻辑,如果这个库不可用,会导致业务不可用
那么如果可靠性优先策略异常切换会出现什么效果
但主库断电的时候,这个时候如果是可靠性优先策略,就必须等待seconds_behind_master=0,才能进行切换,此时的系统已经不可用了,因为我们此时的连接还没有到备库上,但是有人说可以直接切到备库,保持备库只读就可以了,实际上这就会导致主库上的中转日志没有完成,直接切换会导致数据丢失的现象,虽然等待中转日志应用完成,数据就会回来,但是短暂的数据丢失也是不能接受的.我们发现数据库的可用性是依赖主备延迟的时间,延迟时间越少,主备故障时候数据恢复就越小,可用性越高
如果对您有一丝丝帮助,麻烦点个关注,也欢迎转发,谢谢
扫码关注![1026284a76c6f5fbc9a2ce23257592a4.png](https://i-blog.csdnimg.cn/blog_migrate/b7b2b36733669761f66a7781976f0d50.jpeg)