只要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 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日志。
