MySQL日志详解 - Undo/Redo/Binlog

Innodb日志：Undo Log

Undo Log是Innodb引擎特有的日志，记录数据库写操作时的修改记录，与Innodb事务有密切关系。它主要提供两种能力：

1. 事务原子性(Atomicity)
2. 多版本并发控制(MVCC)

作用原理

1. Undo log记录数据库修改的逻辑操作
   • 如一条DELETE操作，对应在Undo Log中会插入一条INSERT记录. 那么如果事务在rollback时，Innodb可以保证所有的变更操作回退，从而实现了事务原子性
2. Undo log在事务开启时产生，一个事务中的所有写操作都会记录其逻辑反向操作
   • 在主键索引中，每一个数据行隐藏了两列信息trx_id和roll pointer，前者标记当前数据值属于哪个事务id，后者提供指向其上一个版本数据的指针；
   • 在数据库并发中，如果事务1读不到行A当前版本的值，那么就可以通过roll pointer找到对应的Undo log段，通过其中的逻辑语句，计算出上一个版本的值。依此类推，从而实现了多版本控制MVCC
3. 正因为同时要支持MVCC的特性，所以Undo log在事务提交时并不会立刻删除。至于删除时机，MySQL有自己的一套判断逻辑，即当所有的快照读都读不到该事务id对应的Undo log时，这个事务id对应的Undo log可以删除，如：
   • 某行数据的变更一次经历了4个版本A -> B -> C -> D，其实D是当前读可以读到最新的版本，A为最老版本。如果此刻系统中所有的活跃事务都可以看到版本B，那么此时A版本对应的Undo log才可以删除

Innodb日志：Redo Log

Redo log又叫做重做日志，是Innodb最为核心的日志之一，redo log可以保证事务的持久性(durability)

作用原理

1. Redo log记录数据库修改中，磁盘数据页的物理变化
   • 每一个事务只会记录一个数据变化的结果，而不会记录数据变化的过程。这点和Undo log是有 区别的，Undo log记录事务中所有逻辑变化的反过程。
2. WAL: Write-Ahead Logging
   • WAL是MySQL中一个重要的技术，即先写日志，再写磁盘。当MySQL中有数据需要更新的时候，MySQL会先把数据变更写到redo log日志，然后再更新MySQL内存，此时更新操作完成，当系统空闲时再把Redo log日志更新到系统磁盘
   • WAL实现了将MySQL更新磁盘的随机IO操作，变成更新Redo Log的顺序IO操作，极大的提高了数据更新效率
3. Redo log日志本身的Crash-safe特性，保证了Innodb事务的持久性
   • Crash-safe指，当系统或服务器宕机时，Redo log依然可以保证数据的完整性和准确性，具体的实现，后面Redo log日志持久化会提到
4. Redo log日志的持久化: Log Buffer && Os Buffer
   • Log Buffer为用户态内存Redo log日志缓存，每次Redo log更新总是先更新Log Buffer
   • Os Buffer为内核态内存Redo log日志缓存，Redo log的刷盘操作，需要先更新到Log Buffer，然后再更新到Os Buffer, 最后通过系统调用fsync，将Os Buffer中的日志落到磁盘中，持久化，总体过程如下：
     • Log Buffer -> Os Buffer -> Log file in disk
   • Mysql 通过Innodb_flush_log_at_trx_commit参数，控制事务提交时，Redo Log持久化行为，可选值为0, 1, 2
     • 0: 表示事务每次提交时，不会主动将Log Buffer数据写到Os Buffer，而是通过异步线程，每秒执行一次Log Buffer到Os Buffer并调用fsync刷新到磁盘的操作
     • 1: 表示事务每次提交时，都执行刷盘操作，即先写到Os Buffer并调用fysnc刷新到磁盘
     • 2: 表示事务每次提交时，仅将Log Buffer的变化写到Os Buffer, 异步线程每秒执行一次fsync系统调用，刷新到磁盘
     • 可以看到，1等级最安全，同时会带来性能消耗；0等级性能最好，但也最不安全，应用异常退出可能存在1s的数据丢失；2等级处于中间状态，先写入Os Buffer，当应用异常退出时数据不会丢失，仅当服务器异常宕机时会有1s的数据丢失；事实上，0和2的性能差距并没有很大，因为2只是多了一步内存的拷贝，性能消耗不高；1由于存在IO，性能消耗较大，但也是最安全的方式，实际应用中可以根据应用场景设置，可以先设置1，如果发现服务性能跟不上，再根据应用场景酌情调整安全等级
5. Redo log的更新方式： CheckPoint && WritePosition
   • Redo log的大小，在系统运行中时固定的。并且在系统运行过程中，是循环写入和擦除的
     • 大小过大，会导致在恢复数据时较慢
     • 大小过下，导致在日志持久化时频繁刷磁盘
   • CheckPoint: 记录当前要擦除的位置，它只能往后移动（移动到文件尾后循环到文件开头），每次移动CheckPoint，都要将移动区间的数据变更更新到MySQL磁盘
   • WritePosition: 记录当前可以写日志的位置，它也只可以向后移动，有新日志写入后，需要移动WritePosition.
     • WritePosition -> CheckPoint 为空白部分，可以写入新日志
     • CheckPoint -> WritePosition 为已写入数据部分。WritePos总是在追逐CheckPoint，追上则说明此时Redo log已满，需要移动CheckPoint并把数据更新写到MySQL数据磁盘
6. Redo log两阶段提交协议
7. Redo log配置查看语句: show variables like '%innodb_log%';

MySQL Server日志：Binlog

Binlog是MySQL Server层的二进制日志，主要记录所有DDL和DML操作记录（除select、show等查询语句），Binlog主要用于

1. 数据同步
2. 数据恢复

作用原理

1. Binlog写入时机
   • 对于Innodb引擎而言，Binlog是在事务提交之后再产生的（目前只讨论Innodb引擎）。
   • Binlog也有类似Redo log的内存数据和磁盘数据两种，并通过参数sync_binlog来控制Binlog的刷盘时机
     • 0: 表示MySQL只将Binlog写入内存，不主动刷入磁盘，由操作系统控制刷盘
     • 1: 表示每一个事务提交，都会将产生的Binlog写入磁盘中
     • >1: sync_binlog > 0表示有多少个事务提交时，将Binlog刷盘，1仅是特例
2. Binlog的日志格式
   • Statement: 记录修改语句
   • Row: 记录每行的修改结果
   • Mixed: 结合以上两者

小结

1. Undo log记录事务中语句的修改，在事务回退，MVCC中用到
2. Redo log记录事务更新后数据内容变化（数据页的物理变化），结合WAL将随机磁盘IO转换为顺序磁盘IO，提高性能；同时Redo log日志本身的刷盘机制，使其自己拥有了crash-safe能力，从而实现了Innodb的数据持久性
3. Binlog是MySQL Server层的日志，记录数据的逻辑修改。用于主从复制和数据恢复