1. 背景
MySQL 实现事务、解体复原、集群的主从复制,底层都离不开日志,所以日志是 MySQL 的精髓所在。只有理解 MySQL 日志,才算是彻底搞懂 MySQL。
明天一灯就带你深入浅出的学习 MySQL 的三大日志零碎,Redo Log(重做日志)、Undo Log(复原日志)、Bin Log(备份日志)。
2. Redo Log(重做日志)
2.1 Redo Log 的内容与作用
Redo Log 记录的是物理日志,也就是磁盘数据页的批改。
作用: 用来保障服务解体后,仍能把事务中变更的数据长久化到磁盘上。
MySQL 事务中持久性就是应用 Redo Log 实现的。
2.2 什么时候写入 Redo Log?
- 从磁盘加载数据到内存
- 在内存中批改数据
- 把新数据写到 Redo Log Buffer 中
- 把 Redo Log Buffer 中数据长久化到 Redo Log 文件中
- 把 Redo Log 文件中数据长久化到数据库磁盘中
你可能会问,为什么须要写 Redo Log Buffer 和Redo Log FIle?间接长久化到磁盘不好吗?
间接写磁盘会有产生重大的性能问题:
- InnoDB 在磁盘中存储的根本单元是页,可能本次批改只变更一页中几个字节,然而须要刷新整页的数据,就很浪费资源。
- 一个事务可能批改了多页中的数据,页之间又是不间断的,就会产生随机 IO,性能更差。
这种计划叫做 WAL(Write-Ahead Logging),预写日志,就是先写日志,再写磁盘。
2.3 Redo Log 刷盘规定
写入 Redo Log Buffer 之后,并不会立刻长久化到 Redo Log FIle,须要期待操作系统调用 fsync() 操作,才会刷到磁盘上。
具体什么时候能够把 Redo Log Buffer 刷到 Redo Log FIle 中,能够通过 innodb_flush_log_at_trx_commit 参数配置决定。
参数值 | 含意 |
---|---|
0(提早写) | 提交事务后,不会立刻刷到 OS Buffer 中,而是等一秒后刷新到 OS Buffer 并调用 fsync()写入Redo Log FIle,可能会失落一秒钟的数据。 |
1(实时写 | 每次提交事务,都会刷新到 OS Buffer 并调用 fsync()写到Redo Log FIle,性能较差 |
2(提早刷新) | 每次提交事务只刷新到 OS Buffer,一秒后再调用 fsync()写入Redo Log FIle。 |
InnoDB 的 Redo Log File 是固定大小的。能够配置为每组 4 个文件,每个文件的大小是 1GB,那么 Redo Log File 能够记录 4GB 的操作。
采纳循环写入笼罩的形式,write pos 记录开始写的地位,向后挪动。checkpoint 记录将要擦除的地位,也是向后挪动。write pos 到 checkpoint 之间的地位,是可写区域,checkpoint 到 write pos 之间的地位是已写区域。
3. Undo Log(回滚日志)
3.1 Undo Log 的内容与作用
Undo Log 记录的是逻辑日志,也就是 SQL 语句。
比方:当咱们执行一条 insert 语句时,Undo Log 就记录一条相同的 delete 语句。
作用:
- 回滚事务时,复原到批改前的数据。
- 实现 MVCC(多版本并发管制,Multi-Version Concurrency Control)。
MySQL 事务中原子性就是应用 Undo Log 实现的。
3.2 Undo Log 如何回滚到上一个版本
实现形式通过两个暗藏列 trx_id(最近一次提交事务的 ID)和 roll_pointer(上个版本的地址),建设一个版本链。并在事务中读取的时候生成一个 ReadView(读视图),在 Read Committed 隔离级别下,每次读取都会生成一个读视图,而在 Repeatable Read 隔离级别下,只会在第一次读取时生成一个读视图。
4. Bin Log(备份日志)
4.1 Bin Log 的内容与作用
Bin Log记录的是逻辑日志,即原始的 SQL 语句,是 MySQL 自带的。
作用: 数据备份和主从同步。
Bin Log共有三种日志格局,能够 binlog_format 配置参数指定。
参数值 | 含意 |
---|---|
Statement | 记录原始 SQL 语句,会导致更新工夫与原库不统一。<br/> 比方 update_time=now() |
Row | 记录每行数据的变动,保障了数据与原库统一,毛病是数据量较大。 |
Mixed | Statement 和 Row 的混合模式,默认采纳 Statement 模式,波及日期、函数相干的时候采纳 Row 模式,既缩小了数据量,又保障了数据一致性。 |
4.2 什么时候写入 Bin Log?
Bin Log采纳追加写入的模式,并不会笼罩原有日志,所以能够用来复原到之前某个时刻的数据。
Bin Log也是采纳 WAL 模式,先写日志,再写磁盘。
至于什么时候刷新到磁盘,能够 sync_binlog 配置参数指定。
参数值 | 含意 |
---|---|
0(提早写) | 每次提交事务都不会刷盘,由零碎本人决定什么时候刷盘,可能会失落数据。 |
1(实时写) | 每次提交事务,都会刷盘,性能较差。 |
N(提早写) | 提交 N 个事务后,才会刷盘。 |
退出写 Bin Log 之后的事务流程:
这就是二阶段提交的概念,先写处于 prepare 状态的 Redo Log,事务提交后,再写处于 commit 状态的 Redo Log。
知识点总结:
文章继续更新,能够微信搜一搜「一灯架构」第一工夫浏览更多技术干货。