mysql中的undo log、redo log 、binlog大致概要

前言

undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）

• undo log，事务的原子性，用于事务回滚和MVCC（存储层，记录查询类）
• redo log，事务的持久性，用于服务器宕机故障恢复（存储层，记录查询类）
• binlog，用于数据备份和主从复制（服务层，记录更新修改类）

1. undo log

事务回滚
本身mysql执行的时候就有事务，这是因为默认有begin 以及 commit 来提交事务，具体通过autocommit 参数，默认是开启的

一条命令如果在中间还没提交事务的时候奔溃，主要通过undo log，保证mysql的原子性。
之所以能保证，是因为事务还没提交之前，会对其mysql 未更改前的数据记录到undo log日志文件，所以可以实现事务回滚
（所谓事务回滚，就是取消现在对应的操作，插入数据回滚就是删除这条数据；删除数据回滚就是插入这条数据，更新数据新值回滚就是更新为旧值）

具体怎么操作记忆，主要通过undo log 内部有一个roll_pointer 指针和一个 trx_id 事务id

• trx_id 记录哪个事务id修改
• roll_pointer 指针将 undo log 串成链表，俗称版本链

MVCC
对应MVCC的实现通过ReadView + undolog

mysql中的事务隔离级别（用到了Read View）：读已提交、可重复读

• 读已提交，每次的select都有新的Read View，表明多次读取数据值会有不同（事务可能多次提交）
• 可重复读，启动事务就会生成一个Read View，保证数据值的一样

总结

• 发生故障的时候，通过undo log将其历史数据恢复到事务开始前的状态
• mysql执行快照读的时候，根据事务Read View信息，顺着undo log的版本链找到记录

2. redo log

redo log是物理日志，执行事务的时候就会产生物理日志。一般事务提交的时候，redo log就会持久化在磁盘（而不需等待缓存Buffer Pool持持久化到磁盘），mysql重启，会根据redo log日志恢复最新状态

为了防止断电数据消失，当有数据更新记录的时候，InnoDB会将其更新内存，对应记录写到redo log日志中
产生的redo log日志不是一开始就写入磁盘（不然会增加多个IO操作），默认就有redo log buffer，通过innodb_log_Buffer_size 来调整buffer的参数。

对应redo log buffer什么时候更新到磁盘中（默认是顺序写，顺序写比随机写要快）
主要有如下场景：

• mysql正常关闭
• redo log buffer记录数据大于buffer本身
• 后台线程的时间间隔1秒，自动更新磁盘
• 事务提交的时候，可通过innodb_flush_log_at_trx_commit 做调整

此处讲解下innodb_flush_log_at_trx_commit 这个参数：（所谓的更新是将redo log buffer 的redo log更新到磁盘）

• 参数为0，事务提交，不会也写入磁盘。主要通过后台线程的时间间隔（1s），通过write()写到操作系统文件缓存，调用fsync()更新到磁盘
• 参数为1，事务提交，会更新到磁盘（默认是这个）
• 参数为2，事务提交，对应将其写入操作系统的文件缓存，直接地调用fsync更新磁盘

以上有两个参数特别注意下，0的时候只有在mysql崩溃才会导致数据丢失，2只有在操作系统奔溃的时候才会导致数据丢失

• 数据安全性：参数 1 > 参数 2 > 参数 0
• 写入性能：参数 0 > 参数 2> 参数 1

redo log文件如果写满，对应会清除
具体内部结构1个redo log group 有2个redo log （使用循环写），环形结构，通过 write pos 表示 redo log 当前记录写到的位置，用 checkpoint 表示当前要擦除的位置

3. binlog

binlog是备份恢复还有主从复制
redo log是故障或者掉电恢复

这两者有些相似，具体有哪些不同

• redo log是循环写，写满就清除，边写边擦除，已经写入的磁盘文件信息会被清除
• binlog是追加写，写满就创新新文件（一般整个数据库被删除，可通过如下恢复）

binlog主要用于主从复制
对应可看我之前的文章：关于主从复制的超详细解析（全）

具体流程大致如下：

1. master将数据的改变记录到二进制日志(binary log)。这些记录过程叫做二进制日志事件，binary log events;当数据发生改变时，则将其改变写入二进制日志中；

2. slave会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件

3. 同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。

一般来说从库不是越多越好，因为从库IO多了，而且需要log dump处理复制的请求，对主库资源消耗比较高