背景
当前几乎所有的关系数据库都采用日志先行的方式，也就是所谓WRITE-AFTER-LOG(WAL)，这是因为日志通常是顺序写的，并且写入量相比修改的数据通常要小很多。通过redo log来确保提交的事务必然具有持久性。（目前也有另外一种理论叫做Write Ahead Log, 由CMU的教授提出，主要适用于Nvme，这里在CMU的peloton项目里有个介绍）
然而日志由于要保证顺序性，需要锁来保护所有日志拷贝到buffer都是有序的，引入了一个严重的锁竞争点，特别是在多核场景下，这里的竞争会非常明显，无法发挥出多核心的优势。
为了解决这个问题，MySQL8.0对日志系统进行了重新设计，将整个模块变成了lock-free的模式（小道消息，目前官方也在对事务模块和锁模块改造成lock-free模式，相信到时候InnoDB的扩展性必然会提升一大截， 未来可期!）
具体的，我们可以对应到几个模块：
- 拷贝到buffer: 每个mini transaction将自己的本地日志拷贝到全局Buffer中- 写磁盘：包括写磁盘和调用fsync进行持久化- 事务提交：当事务undo被标记为prepare(如果binlog打开) 或者commit时，需要确保日志被刷到磁盘，以确保事务的持久性- Checkpoint: 定期对日志做checkpoint，减少崩溃恢复时日志的应用量
以下是对上述几个模块的简要介绍
实现
写log buffer
在5.7版本中，Innodb的log buffer实际上是分成了两个区域，轮换着来写，从而实现在写一个buffer 时，另外一个buffer依然可以继续往里面拷贝日志。但到了8.0版本，所有日志相关的mutex都已经移除了，划分缓冲区域也就没有必要了，而是将log buffer当做一个环来使用。
首先，持有一个s lock, 并通过原子操作获取当前mtr的start_lsn，和sn号(lsn减去log block头和尾的大小，表示有效日志量)，这样相当于在顺序增加的lsn序列中保留了自己的一段范围（获得mtr_t::start_lsn 和mtr_t::end_lsn)， 通过start_lsn取模log buffer size，得到其在log buffer中的位置，然后逐个block进行拷贝（log_buffer_write）, 每写一个mtr log block，就将其start_lsn和end_lsn加入到log.recent_written中，维持了一个link结构, 一个mtr 可能会更新多次link_buf
(InnoDB里增加了一个叫link_buf的类，其具体的作用就是将不连续的变量维护成一个链表，举个简单的例子：
buf[lsn_1] = lsn_2
buf[lsn_2] = lsn_3
Buf[lsn_3] = 0
Buf[lsn_4] = lsn_5
Lsn_1 = 10
Lsn_2 = 100
Lsn_3 = 200
Lsn_4 = 300
Lsn_5 = 400
通过这种方式，实际可以追踪到所有并发写入到buffer的mtr范围，并快速检测到buffer中的hole，例如上例中,lsn_3 ~ lsn_4属于还没有写入日志的空洞 如上提到的log.recent_written, 可以确保写到磁盘的日志不存在空洞，如上例，只能写到lsn_3这个位置)
在拷贝完日志后，就需要将脏块加入flush list中。注意由于现在实现了完全并发，我们无法做到按照LSN顺序插入到flush list上，而有序性是用于保证checkpoint点的正确性。因此在这里同样也引入了另外一个link_buf，名为log.recent_closed，来辅助获取一个安全的checkpoint点。因此在加入flush list后，该mtr也会加入到recent_closed中（类似buf[mtr->start_lsn] - mtr->end_lsn)
注意log.recent_writtern 和log.recent_closed都是有空间限制的，如果超出其capability，就需要等待，但这种情况一般很少见
可以看到这里的代码和5.7及之前版本已经完全不同了：
- 日志可以并发拷贝，但会存在hole
- Flush list不再有序
我们之前惯用log_get_lsn或者直接log_sys->lsn来获得最新的lsn点，而在8.0版本，通过将log.sn转换成最新的lsn，但这个lsn点并不代表该点之前的日志都拷贝到buffer。之前我们提到在拷贝buffer之前需要加一个s_lock， 如果我们在持有x锁的前提下去取lsn，才能保证是最新的。
写磁盘
目前有两个后台线程来做日志持久化，一个是log_writer线程，一个是log_flusher线程，顾名思义，前者负责写日志到磁盘，后者负责fsync日志
Log_writer会根据log.recent_written中的记录找到安全的lsn, 将对应日志写磁盘，同时回收log.recent_written中的空间。 如果当前srv_flush_log_at_trx_commit设置为1的话，还回去唤醒log_flusher线程
log_flusher线程的主要工作是fsync日志文件，同时推进log.flushed_to_disk_lsn。随后尝试去唤醒等待的用户线程（如果只涉及一个event slot)或者唤醒log_flush_notifier线程。
Log_notifier线程专门用于唤醒等待日志写入的线程，根据上次flush的log lsn和当前flush lsn，来计算对应的event slot，并遍历数组唤醒等待的线程。
可以看到这里已经完全做到了异步化，再加上并发拷贝log buffer, 可以极大的发挥硬件性能。
事务提交
在innodb事务提交时，对应的Undo状态被修改后，需要调用log_write_up_to去确保日志已经写盘了。在5.7及之前版本中，该函数就是用于写日志到磁盘。而到了8.0版本，该函数只有唤醒后台线程及等待的逻辑。
一个有趣的问题是，由于目前用户线程仅需要等待唤醒，而无需去操作临界区域，我们可以在其退出innodb后再调用log_write_up_to 进行等待（参考bug#90641）
Checkpoint
由于现在脏页并不是按照LSN顺序写入的，因此选择一个安全的checkpoint点至关重要，这个工作主要由后台线程log_checkpointer来完成。
计算最老lsn的工作在log_get_available_for_checkpoint_lsn中完成：
- 首先找到log.recent_closed中的最小lsn，这个lsn点之前的page肯定已经加入到flushlist上了
- 其次取出当前flushlist中最后一个非临时表page的lsn，并取多个Buffer Pool中的最小值返回，然后减去一个安全的阈值(即log.recent_closed的最大空间)
- 上面两个值去最小的那个
很显然，为了避免扫描全部flush list链表，这里采用了乐观的算法，只要最大限度的保证做checkpoint的点是安全的即可。 这里引入的一个问题是，做checkpoint时可能是在一个mtr log的中间，在崩溃恢复时，可能需要对其定位的log block做特殊处理（在之前的版本中，可以确保checkpoint lsn是一个mtr log的安全边界）
隐藏参数
如上所述，这里引入了多个后台线程来增加系统的并发度，而在内部也有大量参数来对系统进行调整，以获得最优性能，但为了避免引起用户困惑，有一些参数是被隐藏的（在定义时通过PLUGIN_VAR_EXPERIMENTAL来控制）。
如果你想使用这些参数，需要自己去编译mysql代码，并在cmake时增加参数-DENABLE_EXPERIMENT_SYSVARS=1
如下，打开选项后和日志相关的参数包括：
通过这些参数，你可以对新的日志系统进行各种微调来获得最优性能。注意这里很多参数目前还看不到官方文档的描述，你可能需要结合代码来看。有一些比较有趣的参数例如innodb_log_spin_cpu_pct_hwm/lwm 可以控制user cpu超过多少百分比时，是否还允许用户线程继续spin loop。
本文作者：zhaiwx_yinfeng
原文链接
本文为云栖社区原创内容，未经允许不得转载。