日志的写入机制

binlog的写入机制

binlog的写入逻辑比较简单：

事务执行过程中，先把日志写到binlog cache，
事务提交的时候，再把binlog cache写到binlog文件中。

系统给binlog cache分配了一片内存，每个线程一个，参数 binlog_cache_size用于控制单个线程内binlog cache所占内存的大小。如果超过了这个参数规定的大小，就要暂存到磁盘。

write 和fsync的时机，是由参数sync_binlog控制的：

sync_binlog=0：表示每次提交事务都只write，不fsync；(一般不建议将这个参数设成0，比较常见的是将其设置为100~1000中的某个数值。)

sync_binlog=1：表示每次提交事务都会执行fsync；

**sync_binlog=N(N>1)**：表示每次提交事务都write，但累积N个事务后才fsync。(对应的风险是：如果主机发生异常重启，会丢失最近N个事务的binlog日志。)

redo log的写入机制

redo log可能存在的三种状态说起：

存在redo log buffer中，物理上是在MySQL进程内存中，就是图中的红色部分；
写到磁盘(write)**，但是没有持久化（fsync)**，物理上是在文件系统的page cache里面，也就是图中的黄色部分；
持久化到磁盘，对应的是hard disk，也就是图中的绿色部分。

日志写到redo log buffer是很快的，wirte到page cache也差不多，但是持久化到磁盘的速度就慢多了。

为了控制redo log的写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数，它有三种可能取值：

设置为0：表示每次事务提交时都只是把redo log留在redo log buffer中;

设置为1：表示每次事务提交时都将redo log直接持久化到磁盘；

设置为2：表示每次事务提交时都只是把redo log写到page cache。

InnoDB有一个后台线程，每隔1秒，就会把redo log buffer中的日志，调用write写到文件系统的page cache，然后调用fsync持久化到磁盘。

实际上，除了后台线程每秒一次的轮询操作外，还有两种场景会让一个没有提交的事务的redo log写入到磁盘中。

一种是，redo log buffer占用的空间即将达到 innodb_log_buffer_size一半的时候，后台线程会主动写盘。
另一种是，并行的事务提交的时候，顺带将这个事务的redo log buffer持久化到磁盘。

组提交（group commit）机制：

我需要先和你介绍日志逻辑序列号（log sequence number，LSN）的概念。LSN是单调递增的，用来对应redo log的一个个写入点。每次写入长度为length的redo log， LSN的值就会加上length。

一次组提交里面，组员越多，节约磁盘IOPS的效果越好。所以为了让一次fsync带的组员更多，MySQL有一个很有趣的优化：拖时间。

不过通常情况下第3步执行得会很快，所以binlog的write和fsync间的间隔时间短，导致能集合到一起持久化的binlog比较少，因此binlog的组提交的效果通常不如redo log的效果那么好。

如果你想提升binlog组提交的效果，可以通过设置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count来实现。

binlog_group_commit_sync_delay参数，表示延迟多少微秒后才调用fsync;

binlog_group_commit_sync_no_delay_count参数，表示累积多少次以后才调用fsync。

如果你的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。这样做的风险是，主机掉电的时候会丢数据。