合肥网站建设发布,小程序视频网站开发,企业全称网站,在广州学编程有名气的培训班目录主备切换主备延迟的原因可靠性优先策略的主备切换流程可用性优先策略的主备切换流程主备切换
主备切换分为主动运维与被动操作。
软件升级、主库所在机器按计划下线为主动运维。
主库所在机器掉电为被动操作。
同步延迟
1、主库A执行完一个事务#xff0c;写入binlog… 目录主备切换主备延迟的原因可靠性优先策略的主备切换流程可用性优先策略的主备切换流程 主备切换
主备切换分为主动运维与被动操作。
软件升级、主库所在机器按计划下线为主动运维。
主库所在机器掉电为被动操作。
同步延迟
1、主库A执行完一个事务写入binlog时刻T1
2、传给备库B备库B接受完这个binlog时刻T2
3、备库B执行完这个事务时刻T3
同一个事务在备库执行完成的时间和主库执行完成的时间之差为T3-T1又称主备延迟。
在备库执行show slave status命令会显示seconds_behind_master表示备库延迟了多少秒。
主备库机器系统时间设置不一样并不会导致主备延迟的值不准。
在网络正常的时候日志从主库传给备库的时间T2-T1是很短的。也就是说网络正常时主备延迟的主要来源是备库接受完binlog和执行这个事务之间的时间差。
主备延迟最直接的表现就是备库消费中转日志(relay log)的速度比主库生产binlog的速度慢。
主备延迟的原因
1、备库所在机器的性能可能比主库所在的机器性能差
2、备库压力大。主库提供写能力备库提供读能力
由于主库直接影响业务使用起来比较克制反而忽视了备库的压力控制。结果就是备库上的查询耗费了大量的CPU资源影响了同步速度造成主备延迟。
这种情况可以这么解决
1、一主多从。除了备库外可以多接几个从库让这些从库来分担读的压力2、通过binlog输出到外部系统让外部系统提供统计查询的能力3、大事务情况
由于主库必须等事务执行完才会写入binlog再传给备库。
如果一个主库上的语句执行10分钟那么这个事务很可能会导致从库延迟10分钟。
典型大事务场景
a、一次性删掉大量历史数据。需要控制每个事务删除的数据量分成多次删除
b、大表DDL
4、备库并行复制能力差
可靠性优先策略的主备切换流程
在M-M结构下状态1切换到状态2流程如下
1、判断备库B现在的seconds_behind_master如果小于某个值(比如5s)继续下一步否则继续重试这一步
2、把主库A改成只读状态(readonly设置为true)
3、判断备库B的seconds_behind_master直到这个值变为0
4、把备库改成可读写状态(readonly设置为false)
5、把业务请求切换到备库B
step2之后主库A和备库B都处于readonly状态此时系统处于不可写状态直到step5才能恢复。step3比较耗时。
可用性优先策略的主备切换流程
如果强行把上面的step4、5调整到最开始执行也就是说不等主备数据同步直接把连接切到备库B并且让备库B可以读写那么系统几乎没有不可用时间。
这个切换流程称为可用性优先流程不过这个切换的代价就是可能出现数据不一致的情况。
结论如下
1、使用row格式的binlog时数据不一致的问题更容易被发现。使用mixed或者statement格式的binlog时数据很可能就不一致了。
2、主备切换的可用性优先策略会导致数据不一致所以一般情况下使用可靠性优先策略。
下面介绍一个使用可用性优先策略的情形 有一个库的作用是记录操作日志。如果数据不一致可以通过binlog来修补而这个短暂的不一致也不会引发业务问题。 同时业务系统依赖于这个日志写入逻辑如果这个库不可写会导致线上的业务操作无法执行。
如果使用可靠性优先的思路只能等待备库慢慢应用中转日志在备库应用完中转日志且切换成读写状态之前数据库是处于不可用的状态。 这时也不能直接切换到备库B然后保持B库只读。
所以此时就需要用到可用性优先策略。
Mysql的高可用性依赖于主备延迟。主备延迟的时间越小出现故障的时候服务需要恢复的时间就越短可用性就越高
