redo log 和 undo log
undo log：
- 为了实现事务原子性，要么全部完成commit，要么全部回滚rollback，Innodb用于实现mvcc（多版本并发控制）
- 例如：将user=’A’ 改为 user=’B’，则undo log中会记录下user=’A’和事务版本等信息
- 一旦事务完成，所有修改必须被记录下，保证数据一致性（后面redo log解释）
redo log：
- 如果使用undo log作为持久化数据，意味着修改数据和undo log必须同时写入磁盘持久化，这必定带来巨大的磁盘io，解决方案为了平衡磁盘io和一致性，引入redo log。
- 数据和undo log可定时从缓冲刷至磁盘，但是redo log必须实时写入磁盘，当系统奔溃时，可依据redo log进行数据重做。
- InnoDB存储引擎层的日志。
引用自：https://blog.csdn.net/mydriverc2/article/details/50629599
事务的简化过程
假设有A、B两个数据，值分别为1,2，现在修改为3、4
1. 事务开始。
2. 记录A=1到undolog。
3. 修改A=3。
4. 记录A=3到redolog。
5. 记录B=2到undolog。
6. 修改B=4。
7. 记录B=4到redolog，将redolog写入磁盘。
8. 事务提交。bin log和relay log
bin log：
- redo log可以实现数据重做，那为什么要使用binlog？因为redo log是Innodb实现的物理日志，一旦涉及到多种存储引擎，无法进行重做。
- bin log 记录下所有数据的更改，可用于本机数据恢复和主从同步。
- 刷入磁盘的方式：每个1s刷入磁盘 | 每次事务提交刷入磁盘 | 每个1s刷入磁盘+每次事务提交刷入磁盘
- 参考链接
relay（中继） log：
- Mysql 主节点将binlog写入本地，从节点定时请求增量binlog，主节点将binlog同步到从节点。
- 从节点单独进程会将binlog 拷贝至本地 relaylog中。
- 从节点定时重放relay log。