mysql 活跃事务_MySQL日志与事务

系统管理员 2022-10-25 01:47 136阅读 0赞

整体架构

![810fa8149b3fbf88eb514fdc1ec22e87.png][]

事务的基本概念

事务就是一组原子性的sql查询，或者是一个独立的工作单元

事务内的语句，要么全部执行成功，要么全部执行失败

ACID标识原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)

一个运行良好的事务处理系统，必须要具备这些标准特征

原子性

要么所有操作全部成功，要么全部失败回滚，不可能执行其中的一部分操作

一致性

失败后事务最终没有提交，所做的修改不会保存到数据库中

隔离性

事务所做的修改在最终提交前，对其他事务是不可见的

持久性

一旦事务提交，所做的修改就会永久保存到数据库中

事务需要用到更多的处理能力

可选择适合业务的存储引擎

事务的过程就是一个日志的写入过程

以下从缓冲池和日志的角度，描述事务的提交

InooDB体系架构

InnoDB存储引擎有多个内存块，组成一个大的内存池，负责如下工作

维护所有进程/线程需要访问的多个内部数据结构

缓存磁盘上的数据，方便快读地读取，同时在对磁盘文件的数据修改之前在这里缓存

重做日志(redo log)缓冲

![4a914469ff931c14236cf6ea4ec15d0f.png][]

其中，后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存是最近的数据。此外将已修改的数据文件刷新到磁盘，同事保证数据库发生异常的情况下InnoDB能回复到正常运行状态

后台线程

Master Thread

非常核心的后台线程，负责将缓冲池中的数据异步刷新到磁盘，保证数据的一致性

IO Thread

InnoDB存储引擎大量使用了AIO(Async IO异步IO)来处理IO请求，以提高性能。而IO Thread主要负责这些IO请求的回调处理

Purge Thread

回收已提交事务后，不需要的undolog

内存

缓冲池

InnoDB存储引擎基于磁盘存储，记录则按页的方式进行管理

缓冲池用于连接CPU与磁盘速度质检的鸿沟，来提高数据库的整体性能，就是一块内存区域

在读取页的操作，会将磁盘放到缓冲池中(FIX)。下次读取相同页会先从缓冲池里拿

修改时会先修改缓冲池中的页，然后按一定频率刷新到磁盘(通过checnkpoint机制)

缓冲池中缓存的数据页类型有：索引页、数据页、undo页、插入缓冲、自适应哈希索引、InnoDB存储的锁信息、数据字典信息等

![0f4b52b3aaa385470045e104c3b58e18.png][]

LRU List、FreeList和Flush List

LRU

缓冲池通过LRU(Lastest Recent Used，最近最少使用)算法进行管理

最频繁使用的夜放在LRU列表的前端，最少使用的放在尾端

不能存储新读的页时，首先释放LRU尾端的页(页的大小默认为16kb)

InnoDB的LRU算法不是朴素的LRU算法，加入了midpoint位置

默认midpoint位置为5/8处，midpoint之前是old列表、之后是new列表(活跃的热点数据在new列表)

为了防止热点数据从LRU列表中擦除，引入了innodb\_old\_blocks\_time表示读取到mid位置后等待多久才会被加入到LRU列表的热端

Free list

当数据库刚启动，LRU列表是空的，此时页都存放在Free列表中

会先从Free列表中查找是否有可用的空闲页，如有，则放到LRU列表中，否则根据LRU算法淘汰列表末尾的页(不活跃的部分)，分配给新页

InnoDB的策略是尽量使用内存，因此对于一个长期运行的库来说，未被使用的页很少

Flush list

Flush列表中的页都为脏页列表，但脏页也存在于LRU列表中

LRU列表用来管理缓冲池中页的可用性，Flush列表用来管理将页刷新回磁盘，二者互不影响

redo log

redo log buffer

在缓冲池中，有日志缓冲(默认8m)。在写入的时候，会先写入日志缓冲中

以下三种情况，会将日志缓冲刷新到磁盘的重做日志中

Master Thread会每秒都会把日志缓冲的数据刷新到日志文件

每个事务提交(事务commit)

日志重做的缓冲池剩余空间小于1/2时

redo log file

是innoDB本身的日志文件，在存储引擎层

在事务提交时，必须把所有的日志写入到redo log file进行持久化(Write Ahead Log)

重做日志分为多组(至少一组)，每组至少有两个日志文件

以循环的方式写文件，文件1满切换文件2，反之切换回文件1

日志大小太大会导致恢复时间很长，太小，可能会导致多次切换重做日志文件

会导致async checkpoint(下面有解释)，造成性能抖动

checkpoint技术

checkpoint本身是缓冲池

解决了以下问题

缩短数据库的回复时间

缓冲池不够用时，将页刷新到磁盘

重做日志不可用时，刷新脏页

具体来说

通过LSN(Log Sequence Number)来标记版本，缓冲池的页有LSN，重做日志中也有LSN，Checkpoint也有LSN

缓冲池的页会根据LRU算法算出最少使用的页作为脏页，刷回到磁盘

日志可以根据标记的LSN版本，来计算出需要需要重做的日志的部分是哪些

checkpoint的触发有两种

Sharp Checkpoint，在数据库关闭的时候将所有脏页都刷新回磁盘

Fuzzy Checkpoint

Master Thread Checkpoint 以每秒或者每十秒的速度从缓冲池的脏页列表以一定比例的页刷回磁盘

FLUSH\_LRU\_LIST Checkpoint 保证LRU列表中有差不多100个空闲页可用，会从LRU列表尾端的页移除

Async/Sync Flush Checkpoint

当重做日志不可用，则需要强制刷新一些页回磁盘，脏页从脏页列表(Flush List)中选取

写入到重做日志的LSN记为redo\_lsn，已经刷新磁盘最新页的LSN记为checkpoint\_lsn

通过redo\_lsn和checkpoint\_lsn来判断是否需要触发Async/Sync Flush Checkpoint，算法如下

checkpoint\_age = redo\_lsn - checkpoint\_lsn 记录未刷到磁盘的日志

定义变量asycn\_water\_mark = 75% \* total\_redo\_log\_file\_size

定义变量sycn\_water\_mark = 90% \* total\_redo\_log\_file\_size

当async\_water\_mark < checkpoint\_age < sycn\_water\_mark，触发Async Flush，从Flush列表中刷新足够的脏页回磁盘，以满足checkpoint\_age < async\_water\_mark

Dirty Page too much Checkpoint，脏页数量太多，导致强制进行Checkpoint，目的还是为了保证缓冲池有足够可用的页

缩短数据库的恢复时间，在数据更新的时候，会同时更新redo log以及缓冲池缓存，数据库异常(如断电等)的时候，可以直接从checkpoint的点开始从redolog恢复数据

redo log与bin log

redo log是发生在存储引擎这一层，是innodb的日志文件系统，而bin log是在mysql的server层，所有的日志都有

两个日志必须是状态一致的，所以他们的日志写入，则是一个事务的提交过程

bin log记录的是完整的逻辑记录，redo log记录的是物理日志

事务提交的过程，称为两阶段提交

在进行一个事务的时候(未提交)，会把redo log写到缓存buffer中，再通过master thread刷到磁盘中，此时标记为未提交(prepare)

接着在binlog中，写入二进制日志

当binlog写完，再把redo log从prepare状态改为commit，此时事务提交完成

为什么要进行这样的一个提交流程呢？

如果刚好在写入redo log的时候断点，那重启后事务回滚，日志一样同步

如果redo log已经写完，在bin log写入的时候断电，重启后发现二者日志的状态不一致，则事务未提交，根据日志回滚

都写完日志，但未commit，依然回滚

都写完，已commit，状态同步，完成事务提交

二阶段的提交保证了两者日志的一致性

![84374171d3b17882e49e29d2aac3173d.png][]

总结

本文大致描述了事务、缓冲池、checkpoint、日志之间的关联，但还有许多细节需要深究。例如redo log以及undo log的关系、checkpoint的运行机制等等。

参考文档

MySQL技术内幕(InnoDB存储引擎)

高性能MySQL

[810fa8149b3fbf88eb514fdc1ec22e87.png]: /images/20221024/e4df91e62a7f4fc2b0bcfd70220330f9.png
[4a914469ff931c14236cf6ea4ec15d0f.png]: /images/20221024/23d9174f71fa4171b5aa2a1b7d53db75.png
[0f4b52b3aaa385470045e104c3b58e18.png]: /images/20221024/aec8d9446a3f41f1b512362d608f7076.png
[84374171d3b17882e49e29d2aac3173d.png]: /images/20221024/7e4db102b17443eebea3f1bf60ee2482.png