
【mysql】MySQL 中Redo日志与Binlog日志顺序一致性问题
为什么需要二进制日志和事务日志? 事务提交的过程是怎样的?二者是否存在先后顺序问题? 主从复制环境下如何保障数据安全与故障恢复? 为什么要确保二进制日志的写入顺序与InnoDB事务提交顺序保持一致? CrashSafe机制:
发布日期:2021-05-08 11:05:05
浏览次数:24
分类:精选文章
本文共 874 字,大约阅读时间需要 2 分钟。
MySQL 二进制日志与事务日志深入解析
为什么有二进制日志和事务日志?
在MySQL体系结构中,二进制日志(Binary Log)和事务日志(Redo Log)各有其重要作用。二进制日志属于服务器层,主要用于主从复制和即时点恢复。事务日志则属于InnoDB存储引擎层,负责保证事务的安全性。了解了这些基础后,我们可以深入探讨MySQL主从复制的工作原理。
在此过程中,以下问题值得深入探讨:
事务提交过程及其顺序保证
MySQL没有开启二进制日志的情况
在没有开启二进制日志的环境下,InnoDB引擎通过Redo Log和Undo Log来保证CrashSafe特性:
- 所有已提交事务的数据仍然存在。
- 所有未提交事务的数据自动回滚。
InnoDB通过两种机制实现这一点:
- Redo Log:在每次事务提交时,将日志内容写入硬盘。
- Undo Log:记录未提交事务的操作,允许在故障恢复时回滚。
为了平衡性能与CrashSafe特性,InnoDB提供了innodb_flush_log_at_trx_commit
变量,用户可根据需求选择合适的设置。
开启二进制日志的情况
在开启二进制日志的情况下,MySQL引入了两阶段提交(2PC)机制,确保二进制日志与事务日志的一致性:
两阶段提交流程:
- Prepare阶段:生成事务ID(XID),执行Redo Log刷盘操作。
- Commit阶段:
- 将SQL语句写入二进制日志。
- 进行事务提交,清除Undo信息,刷盘Redo Log。
Crash恢复过程:
- 主库在二进制日志写入前崩溃:事务自动回滚,主库数据不变,备库无此事务数据。
- 主库在二进制日志写入后崩溃:事务被认为已提交,备库根据二进制日志完成数据同步。
通过两阶段提交,MySQL确保了主从复制环境下的数据一致性与安全性。