文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

MySQL数据落盘原理(redo、undo、binlog、2PC、double write等。)

2023-10-06 14:00

关注

文章目录


前言

上一章中我们聊到了事务有四大特性:原子性、一致性、隔离性、持久性。本篇文章就持久性重点聊一下,在高性能MySql一书中,对持久性的定义是:一旦事务提交,则起所做的修改就会永久保存到数据库中,此时即使数据库或系统崩溃,修改的数据也不会丢失。
持久性这个概念有点模糊,因为实际上持久性也是分很多种不同的级别的,有些持久性策略能够提供很强的安全保障,有些则未必,并且不可能有能做到100%安全保障的持久性策略,下面我们逐步展开MySQL种事务持久性的真正含义。

ps:基于innodb存储引擎


一、架构图

首先通过几张图片宏观上了解MySQL和innodb的架构

1、MySQL架构图

mysql

2、InnoDB架构图

通过以下两张innodb的架构图可以一目了然的看到innodb数据落盘过程
InnoDB架构图 innodb存储结构图

二、落盘分析

本节是将MySQL落盘过程由浅到深,由简单到复杂逐步分析,来达到理解落盘过程的目的。
落盘1
落盘2

1.第一阶段

假设此时MySQL修改数据后直接写入磁盘,就会有一个问题,数据写入磁盘时随机写的,性能极差,于是有了第二阶段。

2.第二阶段

此阶段增加了缓存这一步,即MySQL修改数据后保存在缓存中,然后由后台线程异步写入磁盘,这个过程也有一个明显的问题,当数据还在缓存中尚未写入磁盘时系统崩溃,会导致数据丢失,安全级别相当差,于是有了第三阶段。

3.第三阶段

此阶段增加了redo log,即更新缓存后,并且同步将redo log写入磁盘,由于redo log是顺序写词盘,所以效率也并不低。这时遇到数据还在缓存中尚未写入磁盘时系统崩溃的情况,MySQL重启是可以根据redo log的内容进行落盘。
但是此时会有脏读,不可重复读等问题,破坏了事务的隔离性。比如A事务更新了缓存但事务尚未提交,B事务去读就会读取到A事务的更新。
这个时候可能有人问了,那A事务更新的时候锁定数据不让B事务读可以吗?可以是可以,但是会导致读性能太差。于是有了第四阶段。

4.第四阶段

此阶段增加了undo log,即在更新缓存前先把对应的反向逻辑日志写到undo log buffer,这样B事务读取事务读取历史版本即可(MVCC机制)。
但是仔细一想还是有问题,那就是MySQL数据落盘是以页为单位的,其大小是16KB,而操作系统的页大小是4KB,如果在落盘的时候操作系统写了12KB时崩溃了,咋办?还有4KB数据呢(这种情况被称为部分写失效),这种情况下MySQL重启如何恢复??
可能有些同学会想通过redo log来恢复,这是不行的,因为redo log记录的是对页的物理操作,如偏移量800,写’aaa’记录,所以redo log生效的前提必须是MySQL数据页是完整的(姜承尧.MySQL技术内幕:InnoDB存储引擎)。
此时在MySQL崩溃重启恢复应用redo log前,需要一个页的副本,当发生部分写失效时,先通过该页的副本来还原该页后再应用redo log,这里所谓的页副本,这种策略就是double write。于是有了第五阶段。

PS:关于undo log落盘
用户定义的临时表的 undo log不刷盘,非临时表的undo log要刷盘的,undo log记录了事务修改前逻辑日志,本质上是数据,和正常表区别不大,它的内容除了记录到undo tablespaces,也会被记录到redo log。其中刷盘到undo tablespaces的机制和正常表数据一致(异步刷盘),刷盘到redo log的机制是和该undo log其对应的redo log一起刷盘的。

5.第五阶段

此阶段增加了double write buffer,先将缓存中的数据搬到该缓冲区,再刷到共享表空间和各个独立表空间,细节如下:

double write由两部分组成,一部分是内存中的double write buffer,大小为2MB,另一部分是物理磁盘上共享表空间中连续的128个页,即2个区(extent),大小同样为2MB。在对缓冲池的脏页进行刷新时,并不直接写磁盘,而是会通过memcpy函数将脏页先复制到内存中的double write buffer,之后通过double write buffer再分两次,每次1MB顺序地写入共享表空间的物理磁盘上,然后马上调用fsync函数,同步磁盘,避免缓冲写带来的问题。在这个过程中,因为double write页是连续的,因此这个过程是顺序写的,开销并不是很大。在完成double write页的写入后,再将double write buffer中的页写入各个表空间文件中,此时的写入则是随机的,开销大。

这样就完美解决了 部分写失效 问题,即使写共享表空间失败,因为还没有写独立表空间,此时直接通过redo log恢复即可,如果写共享表空间成功,写独立表空间部分失败,先通过共享表空间的副本页恢复,再通过redo log恢复。

6.第六阶段

我们知道,在实际项目中,MySQL很少单节点,一般至少主从,双主等,此时必须开启binlog用于主从同步,那么binlog与redo log落盘关系如何呢?
如图所示,此时引入了XA分布式协议,保证binlog和redo log提交顺序。

在MySQL崩溃恢复时,为了保证主从数据一致,检测到binlog完整(redo log至少prepare了),此时提交数据,如果binlog不完整或没有,则回滚数据,回滚用的redo log中的undo log的redo log(太绕了,好好梳理下)。

三、落盘总结

综上所述可知,MySQL的持久化策略也不是100%安全保障的。
由于系统崩溃后的数据提交与回滚基于binlog和redo log,我们先了解下其各自落盘的参数如下:
binlog的重要参数就是sync_binlog:

redo log的重要参数是innodb_flush_log_at_trx_commit:

根据参数含义可知,最安全的就是双1配置,在双1配置下可以得到如下分析:

假设字段name =“tom”,现在执行update语句令name =“Bob”,根据前面章节分析且在得到以下流程:
mysql落盘
根据上图可以清晰的了解到data page,undo log,redo log,binlog四者的落盘先后顺序。

四、崩溃恢复

在讲崩溃恢复之前首先要说一下mysql 崩溃恢复时先rollforward(利用redo log恢复data和undo log),再rollback(利用undo log回滚到历史版本)。

综上可知:
因为binlog已刷盘且完整,会传播到从库,所以mysql为了保证主从一致性,只要binlog完整就提交事务,否则回滚事务。

ps:

来源地址:https://blog.csdn.net/weixin_38597669/article/details/130305313

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯