{{ item.name }}
{{ item.name }}

{{ it.name }}

{{ it.text }}

{{ it.name }}

{{ innerIt.name }}

{{ innerIt.text }}

{{news.time}}
{{news.title}}
Xtrabackup 不备份 binlog 怎么保证一致性?
2022-05-07发布 35,173浏览

公司大佬出的考核题中有个有意思的问题:

已知:MySQL 的内部两阶段提交,是为了解决 binlog 和 redo log 的一致性(在 crash
recovery 的过程中, 如果发现某个事务的 redo log 已经完成 prepare 阶段, 但未完成 commit,那么会验证该事务是否在
binlog 中,如存在,则进行提交,否则进行回滚)。

又已知:Xtrabackup 在恢复备份后,会进行类似于 crash recovery 的动作(将备份的 redo log 的内容回放到数据中,
并对事务进行提交/回滚),那么 Xtrabackup 为什么不需要备份 binlog 文件?

想了一下好像不是能一句话说清楚的,我来尝试解答下。

答:

备份时全局锁阶段做的操作:

备份时全局锁阶段

备份时全局锁阶段

这里最主要是要保证两点:

  • 非事务数据之间一致性;
  • 数据和 binlog 位点的一致性。

其中 FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS,是防止 innodb_flush_log_at_trx_commit
不等于 1 ,redo log没有刷到磁盘。而 SHOW MASTER STATUS 则是为了获取 binlog 位点。

关键在:xtrabackup
只需要保证“数据和 binlog 位点的一致”,而不是“数据和 binlog 的一致”。

crash recovery 过程要保证“数据和binlog的一致”,因为 crash 后不能出现事务重做提交而 binlog
没记录的情况,这样会导致从库丢失数据。那备份需要考虑的是什么?有两点:

  • 备份恢复后,再基于 binlog 做精确恢复时,--start-position 的位置是正确的,不会重放、漏掉事物;
  • 备份恢复后,作为从库向主库复制数据时,复制起始位置是正确的,不会重放、漏掉事物。

其实这两点都一样,就是要保证备份时 “数据和 binlog 位点的一致”。xtrabackup 是怎么实现的呢?

首先我们得知道事务二阶段提交过程中的3个队列 flush、sync、commit 都有排他锁,一个大事务 commit 可能需要几秒钟,那么此时执行
FTWRL 是会被阻塞的,commit 结束后才能取得全局锁,取得全局锁后,执行 commit 会被阻塞:

执行 commit 会被阻塞

执行 commit 会被阻塞

执行 commit 会被阻塞

执行 commit 会被阻塞

这保证了 xtrabackup 备份的 redo log 中只有两种事务:已经完成提交的,和还没开始提交的(未执行 commit
的事务可能被后台线程刷盘),不会出现 prepare 状态的事务。另外还有一个知识点:GTID 的生成和写 binlog 缓存是在二阶段提交的 binlog
flush 阶段做的。结合起来则说明:FTWRL 后 执行 show master status 获取 binlog
位点,只有完成提交的事务才会在其中,所以这保证了 binlog 位点和 binlog 的一致。

所以在 xtrabackup 的恢复过程,不需要处理 prepare 状态的事务,也就不需要再验证该事务是否在 binlog 中了。


上一篇
暂无更多新闻
400-820-6580 13916131869
marketing@actionsky.com
上海市闵行区万源路2138号泓茂中心2号楼
产品详情
关系型数据库
AI数据库
数据库智能管理平台
数据库生态产品
行业案例
金融行业
新零售行业
制造业
通信行业
更多
公司动态
最新新闻
国产化信息
技术分享
关于我们
公司简介
公司分布
国家专利
资质认证
扫码关注公众号
© Copyright 2017, All rights reserved by: 上海爱可生信息技术股份有限公司 沪ICP备12003970号-1 | 法律声明 | 网站地图
沪公网安备 31010402003331号