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参数配置决定。
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配置参数指定。
比如 update_time=now() Row 记录每行数据的变化,保证了数据与原库一致,缺点是数据量较大。 Mixed Statement和Row的混合模式,默认采用Statement模式,涉及日期、函数相关的时候采用Row模式,既减少了数据量,又保证了数据一致性。 4.2 什么时候写入Bin Log?
Bin Log采用追加写入的模式,并不会覆盖原有日志,所以可以用来恢复到之前某个时刻的数据。
Bin Log也是采用WAL模式,先写日志,再写磁盘。
至于什么时候刷新到磁盘,可以sync_binlog配置参数指定。
加入写Bin Log之后的事务流程:
这就是二阶段提交的概念,先写处于prepare状态的Redo Log,事务提交后,再写处于commit状态的Redo Log。
知识点总结:有了MySQL日志的基础,下篇就可以一块学习MySQL集群和主从同步了。
文章持续更新,可以微信搜一搜「 一灯架构 」第一时间阅读更多技术干货。