多宝体育官网-简单回想:MySQL 客户端与管事器间成立荟萃
你的位置:多宝体育官网 > 多宝体育注册 > 简单回想:MySQL 客户端与管事器间成立荟萃
简单回想:MySQL 客户端与管事器间成立荟萃
发布日期:2022-02-18 13:55    点击次数:199

简单回想:MySQL 客户端与管事器间成立荟萃

多宝体育注册

刚看见这个题意见技艺如故有点懵逼的,自后才反馈过来其实问的即是 redo log 的两阶段提交

老章程,背诵版在文末。点击阅读原文不错直达我收录整理的各大厂口试真题

为什么说 redo log 具有崩溃规复的智力

前边咱们说过,MySQL Server 层领有的 bin log 只可用于存档,不及以收场崩溃规复(crash-safe),需要借助 InnoDB 引擎的 redo log 才能领有崩溃规复的智力。所谓崩溃规复即是:即使在数据库宕机的情况下,也不会出现操作一半的情况

至于为什么说 redo log 具有崩溃规复的智力,而 bin log 莫得,咱们先来简单看一下这两种日记有哪些不同点:

1)适用对象不同:

bin log 是 MySQL 的 Server 层收场的,通盘引擎都不错使用

而 redo log 是 InnoDB 引擎独到的

2)写入内容不同:

bin log 是逻辑日记,记载的是这个语句的原始逻辑,比如 “给 id = 1 这一转的 age 字段加 1”

redo log 是物理日记,记载的是 “在某个数据页上做了什么修改”

3)写入格局不同:

bin log 是不错追加写入的。“追加写” 是指 bin log 文献写到一定大小后会切换到下一个,并不会遮盖以前的日记

redo log 是轮回写的,空间固定会被用完

不错看到,redo log 和 bin log 的一个很大的折柳即是,一个是轮回写,一个是追加写。也即是说 redo log 只会记载未刷入磁盘的日记,照旧刷入磁盘的数据都会从 redo log 这个有限大小的日记文献里删除。

而 bin log 是追加日记,保存的是全量的日记。这就会导致一个问题,那即是莫得记号能让 InnoDB 从 bin log 中判断哪些数据照旧刷入磁盘了,哪些数据还莫得。

举个例子,bin log 记载了两条日记:

记载 多宝体育注册1:给 id = 1 这一转的 age 字段加 1 记载 2:给 id = 1 这一转的 age 字段加 1 

假定在记载 1 刷盘后,记载 2 未刷盘时,数据库崩溃。重启后,只通过 bin log 数据库是无法判断这两笔记载哪条照旧写入磁盘,哪条莫得写入磁盘,不论是两条都规复至内存,如故都不规复,对 id = 1 这行数据来说,都是不合的。

但 redo log 不一样,惟有刷入磁盘的数据,都会从 redo log 中被抹掉,数据库重启后,径直把 redo log 中的数据都规复至内存就不错了。

这即是为什么说 redo log 具有崩溃规复的智力,而 bin log 不具备。

redo log 两阶段提交

前边咱们先容过一条 SQL 查询语句的执行过程,简单回想:

MySQL 客户端与管事器间成立荟萃,客户端发送一条查询给管事器;

管事器先查验查询缓存,若是掷中了缓存,则坐窝复返存储在缓存中的效果;不然插驾驭一阶段;

管事器端进行 SQL 默契、预处理,生成正当的默契树;

再由优化器生成对应的执行猜想;

执行器凭据优化器生成的执行猜想,调用相应的存储引擎的 API 来执行,并将执行效果复返给客户端

关于更新语句来说,这套进程相似亦然要走一遍的,不同的是,更新进程还触及两个迫切的日记模块 bin log 和 redo log。

以底下这条简单的 SQL 语句为例,咱们来诠释下执行器和 InnoDB 存储引擎在更新时做了哪些事情:

update table set age = age + 1 where id = 1; 

执行器:找存储引擎取到 id = 1 这一转记载

存储引擎:凭据主键索引树找到这一转,若是 id = 1 这一转处所的数据页底本就在内存池(Buffer Pool)中,就径直复返给执行器;不然,需要先从磁盘读入内存池,然后再复返

执行器:拿到存储引擎复返的行记载,把 age 字段加上 1,得回一转新的记载,然后再调用存储引擎的接口写入这行新记载

存储引擎:将这行新数据更新到内存中,同期将这个更新操作记载到 redo log 内部,此时 redo log 处于 prepare 状况。然后奉告执行器执行完成了,随时不错提交事务

顾惜不要把这里的提交事务和咱们 sql 语句中的提交事务 commit 敕令搞混了哈,咱们这里说的提交事务,指的是事务提交过程中的一个小神志,亦然终末一步。当这个神志执行完成后,commit 敕令就执行收效了。

执行器:生成这个操作的 bin log,并把 bin log 写入磁盘

执行器:调用存储引擎的提交事务接口

存储引擎:把刚刚写入的 redo log 状况改成提交(commit)状况,更新完成

如下图所示:

不错看到,所谓两阶段提交,其实即是把 redo log 的写入拆分红了两个神志:prepare 和 commit。

是以,为什么要这么野心呢?这么野心怎样就或者收场崩溃规复呢?

凭据两阶段提交,崩溃规复时的判断规矩是这么的:

若是 redo log 内部的事务是竣工的,也即是照旧有了 commit 象征,则径直提交

若是 redo log 内部的事务处于 prepare 状况,则判断对应的事务 binlog 是否存在并竣工

a. 若是 binlog 存在并竣工,则提交事务; b. 不然,回滚事务。

虽然,这么说小伙伴们确定没法不竭,底下来看几个本色的例子:

如下图所示,假定数据库在写入 redo log(prepare) 阶段之后、写入 binlog 之前,发生了崩溃,此时 redo log 内部的事务处于 prepare 状况,binlog 还没写(对应 2b),是以崩溃的技艺,这个事务会回滚。

Why?

因为 binlog 还莫得写入,之后从库进行同步的技艺,无法执行这个操作,然而本色上主库照旧完成了这个操作,是认为了主备一致,在主库上需要回滚这个事务

而且,由于 binlog 还没写,是以也就不会传到备库,从而幸免主备不一致的情况。

而若是数据库在写入 binlog 之后,redo log 状况修改为 commit 前发生崩溃,此时 redo log 内部的事务仍然是 prepare 状况,binlog 存在并竣工(对应 2a),是以即使在这个技艺数据库崩溃了,事务仍然会被经常提交。

Why?

因为 binlog 照旧写入收效了,这么之后就会被从库同步曩昔,然而本色上主库并莫得完成这个操作,是认为了主备一致,在主库上需要提交这个事务。

是以,其实不错看出来,处于 prepare 阶段的 redo log 加上竣工的 bin log,就能保证数据库的崩溃规复了。

可能有同学就会问了,MySQL 咋澄澈 bin log 是不是竣工的?

简单来说,一个事务的 binlog 是有竣工神志的(这个咱们在后头的著作中会属目诠释):

statement 神志的 bin log,终末会有 COMMIT row 神志的 bin log,终末会有 XID event

而关于 bin log 可能会在中间出错的情况,MySQL 5.6.2 版块以后引入了 binlog-checksum 参数,用来考证 bin log 内容的正确性。

思考一个问题,两阶段提交是必要的吗?可不能以先 redo log 写完,再写 bin log 或者反过来?

1)关于先写完 redo log 后写 bin log 的情况:

假定在 redo log 写完,bin log 还莫得写完的技艺,MySQL 崩溃。主库中的数据如实照旧被修改了,然而这技艺 bin log 内部并莫得记载这个语句。因此,从库同步的技艺,就会丢失这个更新,和主库不一致。

2)关于先写完 binlog 后写 redo log 的情况:

若是在 bin log 写完,redo log 还没写的技艺,MySQL 崩溃。因为 binlog 照旧写入收效了,这么之后就会被从库同步曩昔,然而本色上 redo log 还没写,主库并莫得完成这个操作,是以从库比拟主库就会多执行一个事务,导致主备不一致

终末放上这道题的背诵版:

口试官:

问法 1:如那儿理 bin log 与 redo log 的一致性问题? 问法 2:一条 SQL 更新语句是如何执行的? 问法 3:讲一下 redo log / redo log 两阶段提交旨趣

小牛肉:

所谓两阶段提交,其实即是把 redo log 的写入拆分红了两个神志:prepare 和 commit。

领先,存储引擎将执行更新好的新数据存到内存中,同期将这个更新操作记载到 redo log 内部,此时 redo log 处于 prepare 状况。然后奉告执行器执行完成了,随时不错提交事务

然后执行器生成这个操作的 bin log,并把 bin log 写入磁盘

终末执行器调用存储引擎的提交事务接口,存储引擎把刚刚写入的 redo log 状况改成提交(commit)状况,更新完成

若是数据库在写入 redo log(prepare) 阶段之后、写入 binlog 之前,发生了崩溃:

此时 redo log 内部的事务处于 prepare 状况,binlog 还没写,之后从库进行同步的技艺,无法执行这个操作,然而本色上主库照旧完成了这个操作,是认为了主备一致,MySQL 崩溃时会在主库上回滚这个事务

 

多宝体育注册

而若是数据库在写入 binlog 之后,redo log 状况修改为 commit 前发生崩溃,此时 redo log 内部的事务仍然是 prepare 状况,binlog 存在并竣工,这么之后就会被从库同步曩昔,然而本色上主库并莫得完成这个操作,是认为了主备一致,即使在这个技艺数据库崩溃了,主库上事务仍然会被经常提交。