doc: 阅读mysql redo log文档

This commit is contained in:
asahi
2025-06-27 00:48:51 +08:00
parent 8fad9108f1
commit 8e90e58987

View File

@@ -78,15 +78,34 @@ redo log重做日志用于实现事务的持久性其由两部分组成
- 内存中的重做日志缓冲redo log buffer - 内存中的重做日志缓冲redo log buffer
- 磁盘中的重做日志文件redo log file - 磁盘中的重做日志文件redo log file
#### redo log persists before transaction committed
innodb存储引擎支持事务其通过`force log at commit`机制实现事务的持久性,即当事务提交时,必须先将该事务的所有日志写入到磁盘的日志文件中进行持久化,直到该过程完成后事务才提交完成。 innodb存储引擎支持事务其通过`force log at commit`机制实现事务的持久性,即当事务提交时,必须先将该事务的所有日志写入到磁盘的日志文件中进行持久化,直到该过程完成后事务才提交完成。
> 上述描述中`提交时将事务所有日志写入到磁盘的日志文件中`,这句话中`日志`代表`redo log 和 undo log`。 > 上述描述中`提交时将事务所有日志写入到磁盘的日志文件中`,这句话中`日志`代表`redo log 和 undo log`。
> - redo log用于保证事务持久性 > - redo log用于保证事务持久性
> - undo log用于帮助事务回滚也用于mvcc功能 > - undo log用于帮助事务回滚也用于mvcc功能
redo log基本都是顺序写的在数据库进程运行时不需要对redo log进行读取操作而数据库进行需要对undo log进行随机读写。 #### redo log和undo log比较
- redo log在mysql server运行时只会被顺序的写入server运行时并不会被读取
- undo log则不同在server运行时可能需要对事务进行回滚或执行mvcc操作此时可能需要对undo log文件进行`随机读写`
#### redo log和binlog的比较
binglog通常用于对数据库进行`point in time`形式的恢复从某个时间点起恢复数据以及主从复制但是binlog和redo log的差别如下
- binlog针对的是mysql数据库级别不止用于innodb还用于其他存储引擎
- redo log属于innodb存储引擎级别
- binlog实际记录的是对应sql语句属于逻辑日志
- redo log实际记录的格式则是物理格式具体为针对某个页面的物理修改
redo log和 bin log日志写入磁盘的时机也有所不同
- bin log`仅在事务提交后才进行一次写入`
- redo log`在事务执行过程中也可能发生写入`redo log buffer满后会写入到磁盘中故而redo log file中同一事务写入的redo log内容可能并非是连续的`多个事务在写入redo log时可能会交叉写入`
#### innodb_flush_log_at_trx_commit #### innodb_flush_log_at_trx_commit
参数`innodb_flush_log_at_trx_commit`用于控制redo log/ undo log刷新到磁盘的策略该参数默认值为`1`,即事务提交时刷新日志到磁盘。除了默认值之外,还可以为该参数设置如下值: 参数`innodb_flush_log_at_trx_commit`用于控制redo log/ undo log刷新到磁盘的策略该参数默认值为`1`,即事务提交时刷新日志到磁盘。除了默认值之外,还可以为该参数设置如下值:
- 0 事务提交时不刷新日志到磁盘仅在master thread中刷新日志到磁盘master thread中刷新操作每秒触发一次 - 0 事务提交时不刷新日志到磁盘仅在master thread中刷新日志到磁盘master thread中刷新操作每秒触发一次
- 1:事务提交时刷新日志,但是仅将日志写入到文件系统的缓存中,`并不进行fsync操作` - 2:事务提交时刷新日志,但是仅将日志写入到文件系统的缓存中,`并不进行fsync操作`
`innodb_flush_log_at_trx_commit`参数设置为`0``2`虽然可以在一定幅度上提高性能但是会丧失数据库的ACID特性。