前言
undo log（回滚日志）、redo log（重做日志） 、binlog （归档日志）
- undo log，事务的原子性，用于事务回滚和MVCC（存储层，记录查询类）
- redo log，事务的持久性，用于服务器宕机故障恢复（存储层，记录查询类）
- binlog，用于数据备份和主从复制（服务层，记录更新修改类）
| 日志 | 区别 |
|---|---|
| undo log | 事务开始前的数据值 |
| redo log | 事务完成后的数据值 |
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主要用于主从复制
对应可看我之前的文章：关于主从复制的超详细解析（全）
具体流程大致如下：
- master将
数据的改变记录到二进制日志(binary log)。这些记录过程叫做二进制日志事件，binary log events;当数据发生改变时，则将其改变写入二进制日志中； - slave会在一定时间间隔内对master二进制日志进行
探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件 - 同时
主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。
一般来说从库不是越多越好，因为从库IO多了，而且需要log dump处理复制的请求，对主库资源消耗比较高
