如何保证 redo log 真实地 写入了磁盘
binlog 的写入逻辑比较简单:事务执行过程中，先把日志写到 binlog cache，事 务提交的时候，再把 binlog cache 写到 binlog 文件中。
一个事务的 binlog 是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这 就涉及到了 binlog cache 的保存问题。
系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控 制单个线程内 binlog cache 所占内存的大小。如果超过了这个参数规定的大小，就要暂 存到磁盘。
事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 中，并清空 binlog cache
write 和 fsync 的时机，是由参数 sync_binlog 控制的:
- sync_binlog=0 的时候，表示每次提交事务都只 write，不 fsync;
- sync_binlog=1 的时候，表示每次提交事务都会执行 fsync;
- sync_binlog=N(N>1) 的时候，表示每次提交事务都 write，但累积 N 个事务后才
fsync。
InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写 到文件系统的 page cache，然后调用 fsync 持久化到磁盘。
注意，事务执行中间过程的 redo log 也是直接写在 redo log buffer 中的，这些 redo log 也会被后台线程一起持久化到磁盘。也就是说，一个没有提交的事务的 redo log，也 是可能已经持久化到磁盘的。
还有两种场景会让一个没有提交的事务的 redo log 写入到磁盘中。
- 一种是，redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时 候，后台线程会主动写盘。注意，由于这个事务并没有提交，所以这个写盘动作只是 write，而没有调用 fsync，也就是只留在了文件系统的 page cache。
- 另一种是，并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁 盘。假设一个事务 A 执行到一半，已经写了一些 redo log 到 buffer 中，这时候有另 外一个线程的事务 B 提交，如果 innodb_flush_log_at_trx_commit 设置的是 1，那么 按照这个参数的逻辑，事务 B 要把 redo log buffer 里的日志全部持久化到磁盘。这时 候，就会带上事务 A 在 redo log buffer 里的日志一起持久化到磁盘。
通常我们说 MySQL 的“双 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说，一个事务完整提交前，需要 等待两次刷盘，一次是 redo log(prepare 阶段)，一次是 binlog。
写 binlog 是分成两步的:
- 先把 binlog 从 binlog cache 中写到磁盘上的 binlog 文件;
- 调用 fsync 持久化。
- redo log 和 binlog 都是顺序写，磁盘的顺序写比随机写速度要快; 2. 组提交机制，可以大幅度降低磁盘的 IOPS 消耗。
如果你的 MySQL 现在出现了性能瓶颈，而且瓶颈 在 IO 上，可以通过哪些方法来提升性能呢
- 设置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 参数，减少 binlog 的写盘次数。这个 方法是基于“额外的故意等待”来实现的，因此可能会增加语句的响应时间，但没有丢 失数据的风险。
- 将 sync_binlog 设置为大于 1 的值(比较常见是 100~1000)。这样做的风险是，主 机掉电时会丢 binlog 日志。
- 将 innodb_flush_log_at_trx_commit 设置为 2。这样做的风险是，主机掉电的时候会 丢数据。
不建议你把 innodb_flush_log_at_trx_commit 设置成 0。因为把这个参数设置成 0， 表示 redo log 只保存在内存中，这样的话 MySQL 本身异常重启也会丢数据，风险太 大。而 redo log 写到文件系统的 page cache 的速度也是很快的，所以将这个参数设置 成 2 跟设置成 0 其实性能差不多，但这样做 MySQL 异常重启时就不会丢数据了，相比之 下风险会更小。
问题 1:执行一个 update 语句以后，我再去执行 hexdump 命令直接查看 ibd 文件内 容，为什么没有看到数据有改变呢?
回答:这可能是因为 WAL 机制的原因。update 语句执行完成后，InnoDB 只保证写完了 redo log、内存，可能还没来得及将数据写到磁盘。
问题 2:为什么 binlog cache 是每个线程自己维护的，而 redo log buffer 是全局共用 的?
回答:MySQL 这么设计的主要原因是，binlog 是不能“被打断的”。一个事务的 binlog 必须连续写，因此要整个事务完成后，再一起写到文件里。
而 redo log 并没有这个要求，中间有生成的日志可以写到 redo log buffer 中。redo log buffer 中的内容还能“搭便车”，其他事务提交的时候可以被一起写到磁盘中。
问题 3:事务执行期间，还没到提交阶段，如果发生 crash 的话，redo log 肯定丢了，这 会不会导致主备不一致呢?
回答:不会。因为这时候 binlog 也还在 binlog cache 里，没发给备库。crash 以后 redo log 和 binlog 都没有了，从业务角度看这个事务也没有提交，所以数据是一致的。
问题 4:如果 binlog 写完盘以后发生 crash，这时候还没给客户端答复就重启了。等客户 端再重连进来，发现事务已经提交成功了，这是不是 bug?
回答:不是。
你可以设想一下更极端的情况，整个事务都提交成功了，redo log commit 完成了，备库 也收到 binlog 并执行了。但是主库和客户端网络断开了，导致事务成功的包返回不回 去，这时候客户端也会收到“网络断开”的异常。这种也只能算是事务成功的，不能认为 是 bug。
实际上数据库的 crash-safe 保证的是:
- 如果客户端收到事务成功的消息，事务就一定持久化了;
- 如果客户端收到事务失败(比如主键冲突、回滚等)的消息，事务就一定失败了;
- 如果客户端收到“执行异常”的消息，应用需要重连后通过查询当前状态来继续后续的
逻辑。此时数据库只需要保证内部(数据和日志之间，主库和备库之间)一致就可以了。
