MySQL原理篇 - InnoDB存储引擎架构设计

2021/12/2 2:06:26

本文主要是介绍MySQL原理篇 - InnoDB存储引擎架构设计,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

前言

InnoDB组件结构:

  1. buffer pool : 缓冲池,缓存磁盘的数据

  2. redo log buffer :记录对缓冲池的操作,根据策略写入磁盘防止宕机但事务已经提交而丢失数据

  3. undo log :当对缓冲池的数据进行修改时,在事务未提交的时候都可以进行回滚,将旧值写入 undo 日志文件便于回滚,此时缓冲池的数据与磁盘中的不一致,是脏数据

1. Buffer Pool

假设现在有一条更新语句:

update users set name = 'lisi' where id = 1

需要更新到数据库,InnoDB会执行哪些操作呢?

图片

首先,InnoDB会判读缓冲池里是否存在 id = 1 这条数据,如果不存在则从磁盘中加载到缓冲池中,而且还会对这行数据加独占锁,防止多个sql同时修改这行数据。

图片

2. undo 日志文件

假设 id = 1 这条数据name原来的值 name = 'zhangsan',现在我们要更新为 name = 'lisi' , 那么我们就需要把旧值name='zhangsan'和id=1这些信息写入到undo日志文件中。

对于熟悉数据库的同学来说都了解事务的概念,在事务未提交之前,所有操作都有可能进行回滚,即可以把 name = 'lisi' 回滚到 name = 'zhangsan',所以将更新前的值写到undo日志文件。

图片

3. 更新buffer pool 数据

在undo日志文件写入完毕之后,便开始更新内存中的这条数据。把 id = 1 的 name = 'zhangsan' 更新为 name = 'lisi'。这时内存中的数据已经更新完毕,但磁盘上的还没有变化,此时出现了不一致的脏数据。

图片

这时可能有一个疑问,万一事务提交完成,但MySQL服务宕机了,而内存中的数据还没写入到磁盘,是不是会造成数据丢失而造成sql执行数据前后不一致?

4. redo log buffer

在InnoDB结构中,有一个 redo log buffer 缓冲区存放redo日志,所谓redo日志,例如 把id=1,name='zhangsan'修改为name='lisi' 便是一条日志。

图片

但这时redo log buffer 还仅仅存在内存中,没能实现MySQL宕机后的数据恢复。

5. 事务没提交,数据库宕机后有影响吗?

其实并没有影响,事务没有提交,意味着执行没有成功,就算MySQL崩溃或者宕机后,内存中的 buffer pool 和 redo log buffer 修改过的数据都会丢失,也并不影响数据前后的一致性。如果事务提交失败,那数据库的数据更加不会改变。

图片

6. 提交事务,redo日志的配置策略

在提交事务时,redo日记会根据策略实现把redo日志从 redo log buffer 里写入磁盘。策略通过 innoDB_flush_log_at_trx_commit 来配置。

  1. innoDB_flush_log_at_trx_commit的参数为0,就算事务提交后,也不会把redo日志写入磁盘。MySQL宕机后会内存中的数据会丢失。

图片

  1. innoDB_flush_log_at_trx_commit的参数为1,事务提交后,redo日志会从内存刷入磁盘,只要事务提交成功,redo log 就必然存在磁盘里。

图片

此时就算buffer pool 的数据没有刷进磁盘,也可以从redo log 中得知修改过哪些数据,MySQL宕机重启后,可以从redo日志中恢复修改的数据。

图片

  1. innoDB_flush_log_at_trx_commit的参数为2,事务提交后,redo log 仅仅停留在 os cache 中,还没刷进磁盘,万一此时服务宕机了。那么os cache 中的数据也会丢失,即使事务提交成功,也会造成数据丢失。

图片

看完这几种相信为了保证数据安全,参数为1是最佳策略。

7. 事务的最终提交,binlog

binlog其实是属于MySQL Server 的日志文件,而在这出提出是因为与redo log有着很大的关联。

1) biglog 与 redo log的区别

  • redo log:记录的是偏物理性质重做日志,比如 “对哪个数据页中的什么记录,做了哪些修改”

  • binlog:偏向于逻辑性的日志,如:“对users表中的id=10的一行数据做了更新操作,更新以后的值是什么”

2) 提交事务的时候同时写入binlog

在执行更新的同时,innoDB与执行器一直在交互,包括加载数据到缓冲池,写入undo日志文件,更新内存数据,写redo日志和刷入磁盘等。而对binlog的写入也是由执行器执行。

图片

其中 1、2、3、4步骤为执行更新语句做的事,而 5、6是提交事务开始做的事。

3) binlog日志刷盘策略分析

sync_binlog参数控制binlog的刷盘策略

  1. sync_ binlog默认值是0,提交事务后,会把binlog日志存在 os cache 中,MySQL宕机后会造成os cache中数据的丢失

  2. sync_binlog 值为1,提交事务后,把binlog日志直接刷入磁盘中。

4) 基于binlog 和 redo log 完成事务的提交

binlog写入磁盘后,会把binlog日志文件所在的位置和文件名称都写入redo log日志文件中,同时在redo log日志文件里写入一个commit标记。

图片

5) commit 标记有什么意义?

commit 标记意义着保持redo log 和 binlog 日志一致。如果在步骤5或者步骤6,事务提交开始,MySQL宕机了,redo log 中并没有commit标记,都算事务提交失败。

意味着 commint 标记是事务最终提交成功。

8. buffer pool 脏数据刷入磁盘

脏数据刷入磁盘是由后台IO线程随机刷入磁盘的。

图片

这时候考虑到,在刷入磁盘之前,MySQL宕机怎么办?这时候,事务已经提交成功,redo log 中也有commit标记,就算宕机了,重启后,也会根据redo日志文件把数据更新到内存中,等待IO线程的刷盘。

9. 总结

通过更新语句执行分析之后,了解到InnoDB存储引擎中包含了 buffer pool 缓冲池、redo log buffer 缓冲区等缓存数据,undo、reod log等日志文件,同时也有MySQL Server 的日志文件。

在执行更新语句的时候,会修改buffer pool、写undo日志文件、 写redo log buffer等操作;提交事务时,会将redo log 刷盘,binlog刷盘,写入binlog文件名称和位置,写入commit标记,最后等待IO线程将buffer pool的脏数据随机刷盘。



这篇关于MySQL原理篇 - InnoDB存储引擎架构设计的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程