MySQL 8.0 redo log的深入解析

前言

最开始了解mysql实现的时候,总听到redo log, WAL(write-ahead logging),undo log这些关键词,了解到redo log主要是用于实现事务的持久化的。为了进一步了解redo log,看了下相关代码(源码版本: mysql 8.0.12),这里简单总结下,主要介绍redo log是如何产生,如何落盘,以及最终通知用户的。

redo log的产生

读写事务在执行的过程中,会不断的产生redo log。申请数据页、修改数据页、记录undo log等,都会产生redo log。mysql将用户事务拆分成一个个mtr(mini transaction),redo log最初产生时就是被记录到mtr中的,并伴随着mtr的提交而提交,最终落到硬盘上。

redo log 的提交

mtr在提交时,会将mtr中的redo log写到系统变量log_sys的log buffer中。mysql8.0一个新特性就是redo log提交的无锁化。在8.0以前,各个用户线程都是通过互斥量竞争,串行的写log buffer,因此能保证lsn的顺序无间隔增长。8.0时用户线程可以并发写log buffer,如果某个用户线程写log buffer成功后,就将自己写的lsn以前的log buffer刷盘,则有可能导致其他用户线程写log buffer还没完成就被刷盘。

MySQL 8.0 redo log的深入解析_第1张图片

为了解决这个问题,mysql 8.0引入了Link_buf这个数据结构来避免log buffer的空洞。Link_buf实际是一个定长数组,像滑动窗口一样跟踪log buffer一段区间的写入情况,随着log buffer中写入连续redo log不断向前推进。

Link_buf的数据结构如图:

MySQL 8.0 redo log的深入解析_第2张图片

当用户在log buffer的start_lsn-end_lsn间写下redo log时,会标记Link_buf相应的位置,即将m_link[start_lsn%m_capacity]赋值为为end_lsn-start_lsn。

redo log记录到log buffer的过程如下:

1.首先,各用户线程写redo log时,先根据redo log长度,向系统全局原子变量log_sys.sn获取本次redo log日志的start_lsn, end_lsn。原子变量sn能保证各线程获得的start_lsn-end_lsn区间连续无空洞;

MySQL 8.0 redo log的深入解析_第3张图片

2.用户线程申请到start_lsn-end_lsn区间后,需要先等待到Link_buf推进到自己可以使用的位置。

MySQL 8.0 redo log的深入解析_第4张图片

如图所示,start_lsn0-end_lsn0,start_lsn2-end_lsn2, start_lsn3-end_lsn3为三个用户线程新申请的lsn区间;start_lsn1-end_lsn1对应的区间已经标记到link_buf上;start_lsn3-end_lsn3距离tail太远,需要等待link_buf推进才能使用;

3.写入log buffer后,再将start_lsn->end_lsn的范围标记到link_buf(注意:因为只在start_lsn%capacity的位置标记link_buf,所以即使end_lsn超过(m_tail, m_tail+m_capacity)也不影响);

MySQL 8.0 redo log的深入解析_第5张图片

4.用户线程提交事务时设置事件log_sys.writer_event,触发log_writer线程将日志从redo log buffer写到系统缓存(log_writer线程自己也会轮询link_buf判断是否写入了新的日志);

5.log_writer线程推进m_tail,并将m_tail前的log buffer落盘。

MySQL 8.0 redo log的深入解析_第6张图片

redo log 的落盘及通知

前面简述了redo log是如何提交的,在redo log提交以及落盘时,涉及多个线程,他们的关系如下:

MySQL 8.0 redo log的深入解析_第7张图片

用户线程在读写事务提交时,会产生一些redo log,并随着mtr提交而记录到redo log buffer中,随后用户线程尝试设置writer_event触发log_writer线程写日志,并监听属于自己的flush_events[i]事件;

log_writer线程推进Link_buf.m_tail,将最大连续lsn前的redo log写入系统缓存,并设置flusher_event触发log_flusher线程;

log_flusher线程将已写入系统缓存的日志刷盘,并设置flush_notifier_event触发log_flush_notifier线程通知用户;

log_flush_notifier根据已刷盘的lsn换算出需要触发的事件,通知用户线程。

具体实现时,通过log_sys中的几个成员变量,跟进redo log的写入情况。其中log_sys.recent_writtern.m_tail表示log buffer最大连续范围;log_sys.write_lsn表示写入到系统缓存的位置;log_sys.flushed_to_disk_lsn表示已落盘的位置。各标记的推进过程如下:

MySQL 8.0 redo log的深入解析_第8张图片

通知用户线程

用户提交事务时,会根据innodb_flush_log_at_trx_commit参数,调用log_wait_for_write或log_wait_for_flush,来等待redo log写入到系统缓存或刷到硬盘。用户线程的通知是通过log_sys.flush_events事件数组来实现的,为了避免一次通知的flush_events过多,flush_events会像桶一样划分给不同的用户线程:redo log是以一个个log block划分的,假设log_sys.flush_events数组长度为m,则第n个log block的刷盘,由flush_events[n%m]事件监听。当log buffer的第L1个log block到第L2个log block被刷盘时,会设置L1-L2之间的log block所属的flush_events,从而redo log在L1-L2之间的用户线程都会收到通知。

MySQL 8.0 redo log的深入解析_第9张图片

总结

mysql8.0通过redo log无锁化,解决了用户线程写redo log时竞争锁带来的性能影响。同时将redo log写文件、redo log刷盘从用户线程中剥离出来,抽成单独的线程,用户线程只负责将redo log写入到log buffer,不再关心redo log的落盘细节,只需等待log_writer线程或log_flusher线程的通知。

以上就是MySQL 8.0 redo log的深入解析的详细内容,更多关于MySQL 8.0 redo log的资料请关注脚本之家其它相关文章!

你可能感兴趣的:(MySQL 8.0 redo log的深入解析)