MySQL 是“怎么保证 redo log 和 binlog 是完整的”

1.事务执行过程中先把日志写到binlog cache ，事务提交的时候再把binlog cache 写入到binlog文件中
2.binlog cache ，系统为每个线程分配了一片binlog cache内存。，参数binlog_cache_size控制单个线程内binlog cache大小。如果超过这个大小就要暂存到磁盘
3.事务提交的时候，执行器把binlog cache 里完整的事务写入binlog中。并清空binlog cache。 4.每个线程都有自己的binlog cache，共用一份binlog文件
5.下图write，是把日志写入到文件系统的page cache，内存中，没有持久化到磁盘，所以速度比较快，图中的fsync是将数据持久化到磁盘，占用磁盘的IOPS

innodb_flush_log_at_trx_commit设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ; 设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘； 设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache。
不建议你把 innodb_flush_log_at_trx_commit 设置成 0。因为把这个参数设置成 0，表示 redo log 只保存在内存中，这样的话 MySQL 本身异常重启也会丢数据，风险太大。而 redo log 写到文件系统的 page cache 的速度也是很快的，所以将这个参数设置成 2 跟设置成 0 其实性能差不多，但这样做 MySQL 异常重启时就不会丢数据了，相比之下风险会更小。


为什么 binlog cache 是每个线程自己维护的，而 redo log buffer 是全局共用的？
这个问题，感觉还有一点，binlog存储是以statement或者row格式存储的，而redo log是以page页格式存储的。page格式，天生就是共有的，而row格式，只跟当前事务相关
statement记录的是更新的SQL，但是要写上下文，因此不能中断，要不同步到从库无法恢复一样的数据内容.