大家好,我是钢板兽!
在上一篇文章中,我分别介绍了 Undo Log、Redo Log 和 Binlog 在事务执行过程中的作用与写入机制。然而,实际应用中,这三种日志的写入是有先后顺序的。因此,本篇文章将深入探讨它们的写入顺序,以便更好地理解三者与事务的联系。
1.涉及的关键缓存
在事务执行过程中,涉及多个重要的缓存机制,理解这些缓存有助于更清晰地掌握日志的写入顺序:
- Buffer Pool(缓冲池)存储 InnoDB 数据页的内存缓冲区,事务修改数据页首先在此处完成,修改后的数据页被称为脏页(Dirty Page)。
- Undo Log Buffer(Undo 日志缓存区) 记录事务修改前的数据版本,存储于内存,在特定时机刷新到磁盘的 Undo 表空间。
- Redo Log Buffer(Redo 日志缓存区) 存储事务修改后的数据变化记录(物理日志),位于内存中,在事务提交时强制刷新到磁盘的 Redo 日志文件。
- Binlog Cache(Binlog 缓存区) MySQL Server层的内存缓存,存储事务中修改的数据变化记录(逻辑变化),在事务提交时统一刷入磁盘的 Binlog 文件。
2.事务执行阶段各日志的写入流程
事务可以分为两个阶段:事务执行阶段和事务提交阶段,假设我们有一个更新事务的SQL语句:
UPDATE account SET balance = balance - 100 WHERE id = 1;
我们先来看看事务执行阶段各日志的写入流程:
(1)数据页加载到buffer pool:从磁盘中加载数据页到buffer pool;
(1)写入Undo Log Buffer:先把待修改数据的原始版本(例如 balance=1000)记录到内存中的 Undo Log Buffer 中。
- 这个 Undo Log Buffer 会在合适时机(后台线程)异步刷新到磁盘(Undo 表空间)。
(3)数据页(脏页)的修改:事务修改内存中的数据页(buffer pool),修改后的数据页变为脏页(Dirty Page),等待后台线程(如checkpoint)异步刷新到磁盘上的表空间文件(.ibd 文件)。
(4)写入Redo Log Buffer:数据库会把修改后的数据记录(例如:balance=900)记录到内存中的 Redo Log Buffer 中。
- Redo Log Buffer 会在以下几种情况下被刷新到磁盘(Redo Log File):
- 事务提交时;
- Redo Log Buffer 达到指定阈值;
- 后台线程定期刷新。
(5)写入Binlog Cache:把SQL语句逻辑记录到内存中的Binlog Cache。
到这里为止(事务未提交阶段),此时的日志情况为:
- Undo Log Buffer 已写入旧版本数据;
- Redo Log Buffer 中包含数据修改后的版本记录;
- Buffer Pool 中的数据页被真正修改,处于内存脏页状态。
- Binlog Cache中包含此次修改的SQL语句逻辑。
3.事务提交阶段
事务提交采用两阶段提交(2PC)机制:Prepare阶段(半提交状态)和Commit阶段(已提交状态),
(1)Prepare状态:InnoDB 存储引擎将 Redo Log Buffer 中的日志记录强制刷入磁盘上的 Redo Log File(调用 write 和 fsync),Undo Log也是同样的过程。
- 此时Redo Log 已持久化,但 Binlog 尚未刷入磁盘。
(2)MySQL层将 Binlog Cache 中的日志记录刷新到磁盘中的Binlog文件(调用 write 和 fsync)。
(3)Commit状态:执行器调用InnoDB存储引擎的提交事务接口,将刚刚写入的Redo Log改成Commit状态
4.为什么要两阶段提交?
这里的两阶段提交主要是针对Redo Log和Binlog来说的,为什么不能是先写Redo Log 后写binlog,或者先写binlog 后写Redo Log就完事儿了呢,还要从中多出一个“Prepare状态”?
(1)假设是先写Redo Log,后写binlog。向表中插入一条数据R,当redolog写入完成,但是binlog还没写时,就出现了宕机.那么主机崩溃恢复时,redolog中是有记录R的,但是从机根据binlog进行主从同步时,从机是没有数据R,就会出现主从数据不一致的问题。
(2)假设先写 binlog 再写 redolog 。向表中插入一条记录 R,先写 binlog 再写 redolog,当binlog写入完成,但是redolog还没写时,就出现了宕机,那么从机根据binlog进行主从同步时,从机是有数据R的。但是主机崩溃恢复时,redolog中是没有记录R的,就会出现主从数据不一致的问题。
但是现在“两阶段提交”,我们再来看几种情况:
(1)一阶段提交之后崩溃了,即写入 redo log,处于 prepare 状态
的时候崩溃了,此时,由于 binlog 还没写,redo log 处于 prepare 状态还没提交,所以崩溃恢复的时候,这个事务会根据undolog来回滚,此时 binlog 还没写,所以也不会传到备库。
(2)写完 binlog 之后崩溃了,此时:redolog 中的日志处于 prepare 状态,还没有提交,那么恢复的时候,首先检查 binlog 中的事务是否存在并且完整,如果存在且完整,则直接提交事务,如果不存在或者不完整,则回滚事务。
(3)假设 redolog 处于 Commit 状态的时候崩溃了,那么重启后的处理方案同情况二。
最后,我们来画图总结一下三种日志在事务过程中的写入顺序:
5.三种日志写入的参数
这里总结一下三种日志的写入过程涉及到的参数变量,可以了解一下。
(1)Redo Log的参数
参数 | 作用 |
---|---|
innodb_log_file_size | 单个 redo log 文件的大小(影响崩溃恢复速度)。 |
innodb_log_files_in_group | redo log 文件数量,默认 2,日志总大小 = innodb_log_file_size × innodb_log_files_in_group 。 |
innodb_flush_log_at_trx_commit | 控制 redo log 刷盘策略,取值: 0 :每秒刷盘一次(可能丢失 1 秒数据) 1 (默认):每次事务提交时写入并刷盘(最安全) 2 :每次事务提交时写入 OS 缓存,但不刷盘(可能丢数据) |
innodb_log_buffer_size | redo log 缓冲区大小,事务提交时才刷盘,缓冲区满了也会刷。 |
(2)Binlog的参数
参数 | 作用 |
---|---|
log_bin | 是否开启 binlog,默认关闭,主从复制和 Point-In-Time 恢复必须开启。 |
binlog_format | binlog 记录格式,取值: STATEMENT (SQL 语句级别,可能有副作用) ROW (记录数据变更,推荐) MIXED (两者结合) |
sync_binlog | 控制 binlog 刷盘策略,取值: 0 :操作系统决定何时刷盘(可能丢数据) 1 (默认):每次事务提交时刷盘(最安全) >1 :每 N 个事务刷一次盘,性能较好但风险增加 |
max_binlog_size | 单个 binlog 文件的大小,超过该值后生成新 binlog(默认 1GB)。 |
expire_logs_days | binlog 自动清理天数,如 7 表示 7 天后自动删除。 |
(3)Undo Log的参数
关键参数:
参数 | 作用 |
---|---|
innodb_undo_tablespaces | undo log 独立表空间数量,默认 0 ,表示undo log全部写入一个表空间文件,可以设置这个变量,平均分配到多少个文件中. |
innodb_undo_log_truncate | 是否允许 undo log 触发在线回收机制,默认 1 ,可防止 undo log 过大。 |
innodb_max_undo_log_size | undo log 触发 truncate 的阈值(默认 1GB)。 |
innodb_undo_logs | 事务可以同时使用的回滚段数量(默认 128 )。 |
通过本篇文章的讲解,相信大家对 Undo Log、Redo Log 和 Binlog 的写入顺序及其重要性有了更深入的理解。如果这篇文章对你有所帮助,欢迎点赞、转发、留言!