内容简介:不等主从同步完成,
- 主库A执行完成一个事务, 写入binlog ,记为
T1
- 然后传给从库B,从库B 接收该binlog ,记为
T2
- 从库B执行完成这个事务,记为
T3
- 同步延时:
T3-T1
- 同一个事务,在 从库执行完成的时间 和 主库执行完成的时间 之间的差值
-
SHOW SLAVE STATUS
中的Seconds_Behind_Master
Seconds_Behind_Master
- 计算方法
- 每个事务的
binlog
里面都有一个 时间字段 ,用于记录该binlog
在 主库 上的写入时间 - 从库取出当前正在执行的事务的时间字段的值,计算它与当前系统时间点差值,得到
Seconds_Behind_Master
- 即
T3-T1
- 每个事务的
- 如果主库与从库的时间不一致,
Seconds_Behind_Master
会不会有误差?- 一般不会
- 在 从库连接到主库 时,会通过
SELECT UNIX_TIMESTAMP()
获取 当前主库的系统时间 - 如果 从库 发现 当前主库的系统时间 与自己的不一致,在计算
Seconds_Behind_Master
会 自动扣除 这部分差值 - 但建立连接后,主库或从库又修改了系统时间,依然会不准确
- 在 网络正常 的情况下,
T2-T1
通常会非常小,此时同步延时的主要来源是T3-T2
- 从库消费
relaylog
的速度跟不上主库生成binlog
的速度
- 从库消费
延时来源
- 从库所在 机器的性能 要弱于主库所在的机器
- 更新请求对于IPOS的压力 ,在 主库 和 从库 上是 无差别 的
- 非对称部署 :20个主库放在4个机器上,但所有从库放在一个机器上
- 主从之间可能会 随时切换 ,现在一般都会采用 相同规格的机器 + 对称部署
- 从库压力大
- 常见场景:管理后台的查询语句
- 从库上的查询耗费大量的 CPU资源 和 IO资源 ,影响了同步速度,造成了 同步延时
- 解决方案
- 一主多从 ,分担读压力,一般都会采用
- 通过
binlog
输出到 外部系统 ,例如Hadoop
- 大事务
- 主库上必须等待 事务执行完成 后才会写入
binlog
,再传给从库 - 常见场景1: 一次性删除太多数据 (如归档的历史数据)
- 解决方案:控制每个事务删除的数据量,分多次删除
- 常见场景2: 大表DDL
- 解决方案:
gh-ost
- 解决方案:
- 主库上必须等待 事务执行完成 后才会写入
- 从库的 并行复制能力 (后续展开)
切换策略
可靠性优先
切换过程一般由专门的 HA
系统完成,存在 不可用时间 (主库A和从库B都处于 只读 状态)
- 判断 从库B 的
Seconds_Behind_Master
值,当 小于 某个值(例如5)才继续下一步 - 把 主库A 改为 只读 状态(
readonly=true
) - 等待 从库B 的
Seconds_Behind_Master
值降为0
- 把 从库B 改为 可读写 状态(
readonly=false
) - 把 业务请求 切换至 从库B
可用性优先
不等主从同步完成, 直接把业务请求切换至从库B ,并且让 从库B可读写 ,这样几乎不存在不可用时间,但可能会 数据不一致
表初始化
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);
插入数据
INSERT INTO t (c) VALUES (4); -- 主库上的其它表有大量的更新,导致同步延时为5S,插入c=4后发起了主从切换 INSERT INTO t (c) VALUES (5);
MIXED
- 主库A执行完
INSERT c=4
,得到(4,4)
,然后开始执行 主从切换 - 主从之间有5S的同步延迟,从库B会先执行
INSERT c=5
,得到(4,5)
,并且会把这个binlog
发给主库A - 从库B执行主库A传过来的
INSERT c=4
,得到(5,4)
- 主库A执行从库B传过来的
INSERT c=5
,得到(5,5)
- 此时主库A和从库B会有 两行 不一致的数据
ROW
- 采用
ROW
格式的binlog
时,会记录新插入行的 所有字段的值 ,所以最后只会有 一行 数据不一致 - 主库A和从库B的同步线程都会 报错并停止 :
duplicate key error
小结
- 使用
ROW
格式的binlog
,数据不一致的问题 更容易发现 ,采用MIXED
或STATEMENT
格式的binlog
,数据可能悄悄地不一致 - 主从切换采用 可用性优先 策略,可能会导致 数据不一致 ,大多数情况下,优先选择 可靠性优先 策略
- 在满足 数据可靠性 的前提下,MySQL的 可用性 依赖于 同步延时 的大小( 同步延时越小 , 可用性越高 )
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 如何提升系统可用性?
- WebP 可用性探测
- 持续交付与可用性
- 可用性高达5个9!支付系统高可用架构设计实战
- 浪潮InCloud OpenStack:度量可用性“三维”,实现高可用云环境
- 特征工程:特征设计、特征可用性评估
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
JavaScript权威指南(第6版)
David Flanagan / 淘宝前端团队 / 机械工业出版社 / 2012-4-1 / 139.00元
本书是程序员学习核心JavaScript语言和由Web浏览器定义的JavaScript API的指南和综合参考手册。 第6版涵盖HTML 5和ECMAScript 5。很多章节完全重写,以便与时俱进,紧跟当今的最佳Web开发实践。本书新增章节描述了jQuery和服务器端JavaScript。 本书适合那些希望学习Web编程语言的初、中级程序员和希望精通JavaScript的JavaSc......一起来看看 《JavaScript权威指南(第6版)》 这本书的介绍吧!