MySQL - 写入binlog和redolog的流程

        只要redo log和binlog保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复，本篇文章探讨MySQL是怎么保证数据不会丢失的。

binlog的写入机制

        binlog的写入逻辑比较简单：事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到 binlog文件中。

        ⼀个事务的binlog是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这就涉及到了binlog cache的保存问题。

        系统给binlog cache分配了一片内存，每个线程一个，事务提交的时候，执行器把binlog cache里的完整事务写入到binlog中，并清空binlog cache：

         可以看到，每个线程有自己的binlog cache，但是共用同一份binlog文件。

• 图中的write，指的就是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快。
• 图中的fsync，才是将数据持久化到磁盘的操作。⼀般情况下，我们认为fsync才占磁盘的IOPS（每秒的读写次数）。

write 和fsync的时机，是由参数sync_binlog控制的：

        1. sync_binlog=0的时候，表示每次提交事务都只write，不fsync；

        2. sync_binlog=1的时候，表示每次提交事务都会执行fsync；

        3. sync_binlog=N(N>1)的时候，表示每次提交事务都write，但累积N个事务后才fsync。

         因此，在出现IO瓶颈的场景里，将sync_binlog设置成⼀个较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，⼀般不建议将这个参数设成0，比较常见的是将其设置为100~1000中的某个数值。

        但是，将sync_binlog设置为N，对应的风险是：如果主机发生异常重启，会丢失最近N个事务的binlog日志。

---

redo log的写入机制

        事务在执行过程中，⽣成的redo log是要先写到redo log buffer 的。

        redo log buffer里面的内容，不需要每次生成后都要直接持久化到磁盘，如果事务执行期间MySQL发生异常重启，那这部分日志就丢了。但是由于事务并没有提交，所以这时日志丢了也不会有损失。

        那么事务还没提交的时候，redo log buffer中的部分日志有没有可能被持久化到磁盘？答案是确实会有此种情况。

        

        我们来看看 redo log可能存在的三种状态，对应的就是图中的三个颜色块：

• 红色部分： 存在redo log buffer中，物理上是在MySQL进程内存中。
• 黄色部分：写到磁盘(write)，但是没有持久化（fsync)，物理上是在文件系统的page cache里面。
• 绿色部分：持久化到磁盘，对应的是hard disk。

         日志写到redo log buffer是很快的，wirte到page cache也差不多，但是持久化到磁盘的速度就慢多了。

        为了控制redo log的写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数，它有三种可能取值：

1. 设置为0的时候，表示每次事务提交时都只是把redo log留在redo log buffer中;

2. 设置为1的时候，表示每次事务提交时都将redo log直接持久化到磁盘；

3. 设置为2的时候，表示每次事务提交时都只是把redo log写到page cache。

        即：

         InnoDB有⼀个后台线程，每隔1秒，就会把redo log buffer中的日志，调用write写到文件系统的page cache，然后调用fsync持久化到磁盘。

        事务执⾏中间过程的redo log也是直接写在redo log buffer中的，这些redo log也会被后台线程⼀起持久化到磁盘。也就是说，⼀个没有提交的事务的redo log，也是可能已经持久化到磁盘的。

        除了后台线程每秒⼀次的轮询操作外，还有两种场景会让⼀个没有提交的事务的redo log写入到磁盘中：

        1. redo log buffer占用的空间即将达到 innodb_log_buffer_size⼀半的时候（即redo log buffer 中记录的写入量大于 redo log buffer 内存空间的一半），后台线程会主动写盘。

        （ 注意，由于这个事务并没有提交，所以这个写盘动作只是write，没有调用fsync，也就是只留在了文件系统的page cache。）

        2. 并行的事务提交的时候，顺带将这个事务的redo log buffer持久化到磁盘。

        （假设⼀个事务A执行到⼀半，已经写了⼀些redo log到buffer中，这时候有另外⼀个线程的事务B提交，如果innodb_flush_log_at_trx_commit设置的是1，那么按照这个参数的逻辑，事务B要把redo log buffer里的日志全部持久化到磁盘。这时候，就会带上事务A在redo log buffer里的日志⼀起持久化到磁盘。）