字节一面:事务还没提交的时候,redolog 能不能被持久化到磁盘呢?
又是被自己菜醒的一天,总结面经看到这题目听都没听过,打开百度就像吃饭一样自然
老规矩,背诵版在文末。点击阅读原文可以直达我收录整理的各大厂面试真题
首先,咱需要明白的是,啥是持久化?
听起来高大上,换句简单的话来说,就是把数据写到磁盘上,也成为落盘。
那为啥要做持久化到磁盘?
目的就是可以在数据丢失后进行恢复,保证数据不丢失。
那么对于 MySQL 来说,只要 binlog 和 redolog 都能正确持久化到磁盘上,就可以保证数据不丢失了。
由此引出文题,不过在讲 redolog 之前,我们还是有必要先来说一下 binlog 的持久化操作。
binlog 持久化
这里引入了一个新的概念:binlog cache
从名字就能看出来,binlog cache 其实就是一片内存区域,充当缓存的作用。
每个线程都有自己 binlog cache 区域,在事务运行的过程中,MySQL 会先把日志写到 binlog cache 中,等到事务真正提交的时候,再统一把 binlog cache 中的数据写到 binlog 文件中。(binlog cache 有很多个,binlog 文件只有一个!)
事实上,这个从 binlog cache 写到 binlog 文件中的操作,并不就是落盘操作了,这里仅仅是把 binlog 写到了文件系统的 page cache 上(这一步对应下图中的 write
操作)。
简单解释下文件系统的 page cache:
CPU 如果要访问外部磁盘上的文件,需要首先将这些文件的内容拷贝到内存中,由于硬件的限制,从磁盘到内存的数据传输速度是很慢的,如果现在物理内存有空余,干嘛不用这些空闲内存来缓存一些磁盘的文件内容呢,这部分用作缓存磁盘文件的内存就叫做 page cache。
很多同学看到这里可能觉得特别特别熟悉,是的,和 CPU 里的高速缓存是不是很像?两者其实都是利用的局部性原理,只不过高速缓存是 CPU 缓存内存的数据,而 page cache 是内存缓存磁盘的数据,这也体现了操作系统内存层次结构分级的思想。
所以,最后需要把 page cache 中的数据同步到磁盘上,才算真正完成了 binlog 的持久化(这一步对应下图中的 fsync
操作)。一般情况下,我们认为 fsync
才占磁盘的 IOPS (Input/Output Operations Per Second)
write 和 fsync 的时机,是由参数 sync_binlog
控制的:
- sync_binlog = 0,每次提交事务的时候,只进行 write,不进行 fsync
- sync_binlog = 1候,每次提交事务的时候,执行 write 和 fsync
- sync_binlog = N(N>1),每次提交事务的时候,执行 write,累积 N 个事务后再执行 fsync
可以看出来,如果业务场景涉及到的 IO 操作很多的话,可以适当增大 sync_binlog
的值,提高性能。但是也存在一定的风险,比如你设置成 100,万一在第 80 个事务提交的时候数据库宕机了,那这些事务的 binlog 日志由于没有执行 fsync,也就丢失了。
redolog 持久化
类比 binlog,在事务执行过程中,binlog 都是存在 binlog cache 中,redolog 也有这样一块内存区域,叫作 redolog buffer。
在事务运行的过程中,MySQL 会先把日志写到 redolog buffer 中,等到事务真正提交的时候,再统一把 redolog buffer 中的数据写到 redolog 文件中。和 binlog 的落盘操作一样,这个从 redolog buffer 写到 redolog 文件中的操作,并不就是落盘操作了,这里仅仅是把 redolog 写到了文件系统的 page cache 上,最后还需要执行 fsync
才能够实现真正的落盘。
解释下 redo log buffer?
在一个事务的更新过程中,日志是要写多次的。比如下面这个事务:
begin;
insert into table1 ...
insert into table2 ...
commit;
这个事务要往两个表 table1 和 table2 中插入记录,为了确保这个事务不被拆开,一次性的完整写入日志文件中,在插入数据的过程中,我们需要把生成的日志都先保存起来。redolog buffer 就是这么一个用来先存 redo 日志的地方。
也就是说,在执行第一条 insert 语句的时候,redolog buffer 也就写入了这条记录的日志。
不同于 binlog cache 每个线程都有一个,redolog buffer 只有那么一个。
事实上,日志写到 redolog buffer 是很快的,wirte 到 page cache 也差不多,但是 fsync 持久化到磁盘的速度就慢多了,为了控制 redo log 的写入策略,InnoDB 提供了 innodb_flush_log_at_trx_commit
参数,它有三种可能取值:
innodb_flush_log_at_trx_commit = 0
,每次事务提交的时候,都只是把 redolog 留在 redolog buffer 中innodb_flush_log_at_trx_commit = 1
,每次事务提交的时候,都执行 fsync 将 redolog 直接持久化到磁盘innodb_flush_log_at_trx_commit = 2
,每次事务提交的时候,都只执行 write 将 redolog 写到文件系统的 page cache 中
说了这么多,各位小伙伴们对 binlog 和 redolog 的持久化机制想必都有所了解了,我们来看文题:事务还没提交的时候,redolog 能不能被持久化到磁盘呢?
先说答案,答案就是有可能。
分析下 redolog 可能存在的三种状态(binlog 也差不多):
- 事务执行过程中,存在 MySQL 的进程内存中的 redolog buffer 中
- 事务提交,执行 write 操作存在文件系统的 page cache 中,但是没有执行 fsync 操作持久化到磁盘
- 事务提交,执行 fsync 操作持久化到磁盘
至于为什么说事务还没提交的时候,redolog 也有可能被持久化到磁盘呢?
InnoDB 有一个后台线程,每隔 1 秒轮询一次,具体的操作是这样的:调用 write 将 redolog buffer 中的日志写到文件系统的 page cache,然后调用 fsync 持久化到磁盘。而在事务执行中间过程的 redolog 都是直接写在 redolog buffer 中的,也就是说,一个没有提交的事务的 redolog,也是有可能会被后台线程一起持久化到磁盘的。
另外,除了后台线程每秒一次的轮询操作外,还有两种场景会让一个没有提交的事务的 redolog 写盘:
innodb_flush_log_at_trx_commit 设置是 1,这样并行的某个事务提交的时候,就会顺带将这个事务的 redolog buffer 持久化到磁盘
举个例子,假设事务 A 执行到一半,已经写了一些 redolog 到 redolog buffer 中,这时候有另外一个事务 B 提交,按照 innodb_flush_log_at_trx_commit = 1 的逻辑,事务 B 要把 redolog buffer 里的日志全部持久化到磁盘,这时候,就会带上事务 A 在 redolog buffer 里的日志一起持久化到磁盘
redo log buffer 占用的空间达到 redolo buffer 大小(由参数
innodb_log_buffer_size
控制,默认是 8MB)一半的时候,后台线程会主动写盘。不过由于这个事务并没有提交,所以这个写盘动作只是 write 到了文件系统的 page cache,仍然是在内存中,并没有调用 fsync 真正落盘
最后放上这道题的背诵版:
面试官:
- 问题:事务还没提交的时候,redo log 能不能被持久化到磁盘呢?
- 相关问题:MySQL 是如何保证数据不丢失的呢?
小牛肉:事务还没有提交的时候,redo log 是有可能被持久化到磁盘的。
redolog 的具体落盘操作是这样的:在事务运行的过程中,MySQL 会先把日志写到 redolog buffer 中,等到事务真正提交的时候,再统一把 redolog buffer 中的数据写到 redolog 文件中。不过这个从 redolog buffer 写到 redolog 文件中的操作也就是 write 并不就是落盘操作了,这里仅仅是把 redolog 写到了文件系统的 page cache 上,最后还需要执行 fsync 才能够实现真正的落盘。
也就是说,redolog 其实存在三种状态:
- 事务执行过程中,存在 MySQL 的进程内存中的 redolog buffer 中
- 事务提交,执行 write 操作存在文件系统的 page cache 中,但是没有执行 fsync 操作持久化到磁盘
- 事务提交,执行 fsync 操作持久化到磁盘
额为什么说事务还没提交的时候,redolog 也有可能被持久化到磁盘呢?
主要有三种可能的原因:
- 第一种情况:InnoDB 有一个后台线程,每隔 1 秒轮询一次,具体的操作是这样的:调用 write 将 redolog buffer 中的日志写到文件系统的 page cache,然后调用 fsync 持久化到磁盘。而在事务执行中间过程的 redolog 都是直接写在 redolog buffer 中的,也就是说,一个没有提交的事务的 redolog,也是有可能会被后台线程一起持久化到磁盘的。
- 第二种情况:innodb_flush_log_at_trx_commit 设置是 1,这个参数的意思就是,每次事务提交的时候,都执行 fsync 将 redolog 直接持久化到磁盘(还有 0 和 2 的选择,0 表示每次事务提交的时候,都只是把 redolog 留在 redolog buffer 中;2 表示每次事务提交的时候,都只执行 write 将 redolog 写到文件系统的 page cache 中)。举个例子,假设事务 A 执行到一半,已经写了一些 redolog 到 redolog buffer 中,这时候有另外一个事务 B 提交,按照 innodb_flush_log_at_trx_commit = 1 的逻辑,事务 B 要把 redolog buffer 里的日志全部持久化到磁盘,这时候,就会带上事务 A 在 redolog buffer 里的日志一起持久化到磁盘
- 第二种情况:redo log buffer 占用的空间达到 redolog buffer 大小(由参数
innodb_log_buffer_size
控制,默认是 8MB)一半的时候,后台线程会主动写盘。不过由于这个事务并没有提交,所以这个写盘动作只是 write 到了文件系统的 page cache,仍然是在内存中,并没有调用 fsync 真正落盘
大厂面试火箭计划
准备面试的小伙伴可以参考我的 Notion 笔记呀:https://flying-veal.notion.site/,总结了很多大厂面试题,提供背诵版和详解版,应该对小伙伴们有所帮助~
字节一面:事务还没提交的时候,redolog 能不能被持久化到磁盘呢?的更多相关文章
- git删除已经提交的包含敏感信息的文件(还没提交到远程仓库)
写好的代码已经提交了(但还没push到github),发现某个文件里包含密码.如果push的话,密码可就被公开了.如果在代码里改掉密码,再commit一次,也不行,历史提交记录还是会上传到github ...
- 谁还没遇上过NoClassDefFoundError咋地——浅谈字节码生成与热部署
谁还没遇上过NoClassDefFoundError咋地--浅谈字节码生成与热部署 前言 在Java程序员的世界里,NoClassDefFoundError是一类相当令人厌恶的错误,因为这类错误通常非 ...
- nestd事务如果报错了 则回滚到外部事物保存点 且外部事物如果没异常的话 会正常提交 nested事务并不会提交;如果外部事物报错了 内部事务会一同回滚
nestd事务如果报错了 则回滚到外部事物保存点 且外部事物如果没异常的话 会正常提交 nested事务并不会提交:如果外部事物报错了 内部事务会一同回滚
- .Net Actor 服务端开发框架,Newbe.Claptrap 项目周报 1 - 还没轮影,先用轮跑
Newbe.Claptrap 项目周报 1,第一周代码写了一点.但主要还是考虑理论可行性. 第一次接触本框架的读者,可以先点击此处阅读本框架相关的基础理论和工作原理. 周报是啥? 成功的开源作品,离不 ...
- PHP PDO 事务与自动提交
现在通过 PDO 连接上了,在开始进行查询前,必须先理解 PDO 是如何管理事务的. 事务支持四大特性(ACID): 原子性(Atomicity) 一致性(Consistency) 隔离性(Isola ...
- 不会吧,你连Java 多线程线程安全都还没搞明白,难怪你面试总不过
什么是线程安全? 当一个线程在同一时刻共享同一个全局变量或静态变量时,可能会受到其他线程的干扰,导致数据有问题,这种现象就叫线程安全问题. 为什么有线程安全问题? 当多个线程同时共享,同一个全局变量或 ...
- 升级过log4j,却还没搞懂log4j漏洞的本质?
摘要:log4j远程代码漏洞问题被大范围曝光后已经有一段时间了,今天完整讲清JNDI和RMI以及该漏洞的深层原因. 本文分享自华为云社区<升级过log4j,却还没搞懂log4j漏洞的本质?为你完 ...
- 在各方面还没准备好的时候,大家一定要慎用border-box样式!!!!
这几天,我被一个js问题困扰到癫狂了! 事情是这样的,我之前写了个功能非常复杂的纯jquery代码的前端gridview控件,实现了大量的功能和效果,在一些项目里也用得很好. 最近有个项目,样式做了调 ...
- 成功熬了四年还没死?一个IT屌丝创业者的深刻反思
三个IT屌丝创业的故事 从前有三个屌丝,聚在一起做网络.提供免费的网络服务,砸锅卖铁,通宵达旦,除了卖肾,啥都做了.3年后终于做到了五百万用户.对于年轻人来说,能把五百万人玩弄于鼓掌之间,已经是很牛逼 ...
随机推荐
- LuoguP7534 [COCI2016-2017#4] Kartomat 题解
Content 火车站里头有一个售票机,其键盘可以看作是一个 \(4\times 8\) 的矩阵,其中第一行的前面三个键和最后一行的最后三个键都是 *,剩余的键按照从上到下,从左到右的顺序依次按照 A ...
- hashlib加密模块主要提供 SHA1, SHA224, SHA256, SHA384, SHA512 ,MD5 算法,HMAC消息签名(HMAC-SHA1,....)
hashlib模块 用于加密相关的操作,3.x里代替了md5模块和sha模块,主要提供 SHA1, SHA224, SHA256, SHA384, SHA512 ,MD5 算法 MD5 摘要输出 # ...
- RabbitMQ 消息队列 实现RPC 远程过程调用交互
#!/usr/bin/env python # Author:Zhangmingda import pika,time import uuid class FibonacciRpcClient(obj ...
- win10使用照片查看器查看图片
1.关于 演示环境: win10 1909 2.习惯win7的照片查看器 如果你习惯使用win7的照片查看器在win10查看照片,可以通过下面的注册表代码实现.方法:1.创建 后缀名为 .reg的文件 ...
- 【九度OJ】题目1176:树查找 解题报告
[九度OJ]题目1176:树查找 解题报告 标签(空格分隔): 九度OJ http://ac.jobdu.com/problem.php?pid=1176 题目描述: 有一棵树,输出某一深度的所有节点 ...
- 【LeetCode】872. Leaf-Similar Trees 解题报告(Python)
作者: 负雪明烛 id: fuxuemingzhu 个人博客: http://fuxuemingzhu.cn/ 目录 题目描述 题目大意 解题方法 中序遍历 先序遍历 后序遍历 日期 题目地址:htt ...
- The Many Faces of Robustness: A Critical Analysis of Out-of-Distribution Generalization (DeepAugment)
目录 概 主要内容 ImageNet-R StreetView StoreFronts (SVSF) DeepFashion Remixed DeepAugment 实验结论 代码 Hendrycks ...
- TensorFlow.NET机器学习入门【7】采用卷积神经网络(CNN)处理Fashion-MNIST
本文将介绍如何采用卷积神经网络(CNN)来处理Fashion-MNIST数据集. 程序流程如下: 1.准备样本数据 2.构建卷积神经网络模型 3.网络学习(训练) 4.消费.测试 除了网络模型的构建, ...
- [opencv]二维码识别开发流程及问题复盘总结
项目复盘总结 开发需求: 在桌面机器人(向下俯视)摄像头拍摄到的图像中做条形码识别与二维码识别. 条形码在图像固定位置,二维码做成卡片的形式在固定区域内随意摆放. 开发环境及相关库:ubuntu 18 ...
- CS5266 Type-C转HDMI+PD3.0+USB3.0 三合一拓展坞电路设计
CS5266 Type-C转HDMI+PD3.0+USB3.0 三合一拓展坞电路设计 CS5266是一款带PD3.0快充 Type-C转HDMI 4K30HZ音视频转换芯片.CS5266支持PD3.0 ...