做羞羞的事的网站,一个好的网站需要具备什么,frontpage制作个人网页教程,八大电商平台是哪几家回滚整个事务要怎么清除 binlog 日志#xff0c;InnoDB 又会进行哪些操作#xff1f; 作者#xff1a;操盛春#xff0c;爱可生技术专家#xff0c;公众号『一树一溪』作者#xff0c;专注于研究 MySQL 和 OceanBase 源码。 爱可生开源社区出品#xff0c;原创内容未经授…回滚整个事务要怎么清除 binlog 日志InnoDB 又会进行哪些操作 作者操盛春爱可生技术专家公众号『一树一溪』作者专注于研究 MySQL 和 OceanBase 源码。 爱可生开源社区出品原创内容未经授权不得随意使用转载请联系小编并注明来源。 本文基于 MySQL 8.0.32 源码存储引擎为 InnoDB。 正文
1. 准备工作
创建测试表
CREATE TABLE t1 (id int unsigned NOT NULL AUTO_INCREMENT,i1 int DEFAULT 0,PRIMARY KEY (id) USING BTREE,KEY idx_i1 (i1)
) ENGINEInnoDB DEFAULT CHARSETutf8mb3;插入测试数据
INSERT INTO t1 (id, i1) VALUES
(10, 101), (20, 201),
(30, 301), (40, 401);示例 SQL
/* 1 */ begin;
/* 2 */ insert into t1(id, i1)values(50 501);
/* 3 */ insert into t1(id, i1)values(60 601);
/* 4 */ rollback;每条 SQL 前面的数字是它的编号4 条 SQL 分别为 SQL 1、SQL 2、SQL 3、SQL 4其中SQL 4 是本文的主角。
SQL 2 插入记录 id 50, i1 501 产生的 undo 日志编号为 0。
SQL 3 插入记录 id 60, i1 601 产生的 undo 日志编号为 1。
2. binlog 回滚
示例 SQL 的两条 insert 语句执行过程中会产生 binlog 日志存放到 trx cache 中。
回滚整个事务时事务执行过程中改变插入、更新、删除的数据都不要了产生的 binlog 日志也就没有用了。
回滚整个事务首先要进行的步骤就是 binlog 回滚。从这个步骤的名字来看我们预期 MySQL 会在这一步把 trx cache 中的 binlog 日志都清除。
不过我们要失望了因为这一步什么都没干。
下面是 binlog 回滚的代码
static int binlog_rollback(handlerton *, THD *thd, bool all) {DBUG_TRACE;int error 0;if (thd-lex-sql_command SQLCOM_ROLLBACK_TO_SAVEPOINT)error mysql_bin_log.rollback(thd, all);return error;
}从代码可以看到只有 thd-lex-sql_command 为 SQLCOM_ROLLBACK_TO_SAVEPOINT 才会调用 mysql_bin_log.rollback(thd, all) 执行 binlog 回滚操作。
然而执行 rollback 语句时thd-lex-sql_command 为 SQLCOM_ROLLBACK不满足 if 条件上面的代码就什么都不会干了。
那么trx cache 中的 binlog 日志什么时候会清除
别急后面会有专门的小节介绍。
3. InnoDB 回滚
binlog 回滚操作结束之后接下来就是 InnoDB 回滚了。
InnoDB 回滚操作会读取并解析事务产生的所有 undo 日志并执行产生这些 undo 日志的操作的反向操作也就是回滚。
回滚过程中会根据 undo 日志产生的时间从后往前读取并解析日志再执行这条日志对应的回滚操作。
示例 SQL 中执行了两条 insert 语句会产生两条 undo 日志编号分别为 0、1。以主键索引为例回滚过程如下
读取最新的 undo 日志编号为 1。解析 undo 日志得到 id 60。删除 t1 表中 id 60 的记录。读取上一条 undo 日志编号为 0。解析 undo 日志得到 id 50。删除 t1 表中 id 50 的记录。读取上一条 undo 日志没有了InnoDB 回滚操作结束。
4. 提交事务
InnoDB 回滚操作完成之后接下来要怎么办
这其实取决于回滚操作是怎么进行的。
我最初理解的回滚操作是把事务执行过程中改变插入、更新、删除的记录恢复原样就像事务什么都没干过一样。
然而实际情况没有这么理想。
事务执行过程中改变过的那些记录回滚之后
从逻辑上来看恢复了原样确实就像事务什么都没干过一样。从物理上来看可能已经发生了变化因为记录的位置有可能和修改之前不一样。
唠叨这么多就是想说清楚一件事事务的回滚操作不是原地撤销对数据页的修改而是通过再次修改数据页实现的。
既然修改了数据页那就需要执行提交操作才能让这些修改生效。
接下来要执行的操作就是把 InnoDB 回滚操作过程中对数据页的修改提交了也就是提交事务。
不过这里的提交事务和 commit 语句提交事务不一样。
执行 commit 语句时因为有 binlog 和 InnoDB 两个存储引擎需要使用二阶段提交。
事务执行过程中改变插入、更新、删除记录会产生 binlog 日志。
回滚时要把记录再修改回原来的样子。从逻辑上来看记录就像是从来没有发生过变化binlog 日志也就不需要了。
所以InnoDB 回滚完成之后提交事务不需要把 trx cache 中的 binlog 日志写入 binlog 日志文件并刷盘只需要提交 InnoDB 事务就可以了。
关于提交 InnoDB 事务的具体逻辑可以参照第 11 期《InnoDB 提交事务提交了什么》。
5. 清除 binlog 日志
trx cache 中的 binlog 日志有可能一部分存放在内存 buffer 中另一部分存放在磁盘临时文件中。
清除操作需要同时清除 trx cache 内存 buffer 和磁盘临时文件中的 binlog 日志分为两个步骤进行
清空内存 buffer让 trx cache 的 write_pos 指向内存 buffer 的开始处即可。清空磁盘临时文件首先会把文件的 seek offset 设置为 0让文件本身的位置指针指向文件开头处然后截断磁盘临时文件释放文件占用的空间。
前面的 binlog 回滚步骤没有清除事务执行过程中产生的 binlog 日志而是留到 InnoDB 回滚步骤中提交事务完成之后才执行。这是因为
清空磁盘临时文件中 binlog 日志的过程不可逆如果中间出现问题不能回退。InnoDB 回滚步骤中提交事务的容错性更好回滚失败之后就不清除 binlog 日志了也不损失什么。
6. 总结
回滚整个事务主要分为三大步骤。
第 1 步执行 binlog 回滚操作其实什么也没干。
第 2 步执行 InnoDB 回滚操作会把事务执行过程中改变插入、更新、删除的记录恢复原样至少从逻辑上来看是这样的。
最后还会提交 InnoDB 事务让回滚操作对数据页的修改生效。
第 3 步清除事务执行过程中产生的、临时存放于 trx cache 中的 binlog 日志。 本期问题关于本期内容如有问题欢迎留言交流。 更多技术文章请访问https://opensource.actionsky.com/
关于 SQLE
SQLE 是一款全方位的 SQL 质量管理平台覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库为开发和运维提供流程自动化能力提升上线效率提高数据质量。
SQLE 获取
类型地址版本库https://github.com/actiontech/sqle文档https://actiontech.github.io/sqle-docs/发布信息https://github.com/actiontech/sqle/releases数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
