只要redo log 和binlog 保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复。

MySQL写入binlog 和redo log 的流程：

binlog 的写入机制

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

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

系统给binlog cache 分配了一片内存，每个线程一个，参数binlog_cache_size用于控制单个线程内binlog cache所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。事物提交的时候，执行器把binlog cache里的完整事物写入到binlog 中，并清空binlog cache。

binlog写盘状态

可以看到，每个线程都有自己的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 的写入机制