redo log 和 bin log 写入机制

在之前的文章里，MySQL中 redo log 的两阶段提交_mysql redolog两阶段提交-CSDN博客

我说明了一次事务提交需要 redo log 和 binlog 配合两阶段提交，才能保证事务执行时数据的一致性

那么，redo log 和 binlog 真正的写入方式是什么，在内存中写还是直接写磁盘？每次事务都会写磁盘吗？

来仔细研究一下 redo log 和 binlog 的写入机制

binlog 写入机制

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

binlog cache 是内存中的一片区域，系统会给每个线程分配一个 binlog cache

参数 binlog_cache_size 可以用于控制单个线程内 binlog cache 的大小，如果超过了这个参数规定的大小，就要暂存到磁盘

binlog cache 在内存中，重启之后数据会丢失，只有把数据写入到位于磁盘上的 binlog，才能保证数据持久化下来

binlog cache 什么时候持久化，由参数 sync_binlog 控制

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

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

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

所谓的 write，就是把日志写入到文件系统的 page cache 中，page cache 是数据持久化到磁盘的缓冲区，write 过程并没有真正把数据持久化到磁盘，速度比较快

fsync，就是持久化操作，要把日志真正写入到磁盘上的 binlog 中，fsync 涉及到磁盘操作，速度会慢

在数据一致性比较高的场景下， 把 sync_binlog 设置为 1，可以减少故障的概率，但是 磁盘IO 过大会导致性能下降，在出现 IO 瓶颈的场景里，将 sync_binlog 设置成一个比较大的值，可以提升性能，但有对应的风险：如果主机发生异常重启，会丢失最近执行的事务的 binlog 日志

redo log 写入机制

redo log 的写入也差不多

先来回顾一下两阶段提交，一个事务执行时，日志写入流程是：redo log 写入处于 prepare 阶段的记录 ---> binlog 写记录 ---> redo log 写入 commit 阶段的记录

实际上，redo log 在 prepare 阶段写入的记录，不是直接写入到 redo log 中，而是先写到 redo log buffer 中

redo log buffer，也是一片内存，用来先存 redo log 日志，因为在事务 commit 之前，这个事务都不能算真正执行，redo log 中存的是事务执行后产生的修改，自然不能在事务执行期间就直接写 redo log，一是会错，二是 redo log 在磁盘上，每次都写磁盘开销太大

真正要往 redo log 中写，发生在两阶段提交的最后一步，redo log 写入 commit 阶段的记录，这一步实际上就是把 redo log cache 中的记录持久化到磁盘上的 redo log 文件中

什么时候做持久化，由参数 innodb_flush_log_at_trx_commit 控制，它有三种可能取值：

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

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

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

不建议把 innodb_flush_log_at_trx_commit 设置成 0。因为把这个参数设置成 0，表示 redo log 只保存在内存中，这样的话 MySQL 本身异常重启也会丢数据，风险太大。而 redo log 写到文件系统的 page cache 的速度也是很快的，所以将这个参数设置成 2 跟设置成 0 其实性能差不多，但这样做 MySQL 异常重启时就不会丢数据了，相比之下风险会更小