MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝

本文涉及的产品
云数据库 RDS SQL Server,基础系列 2核4GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。

读书心得笔记:500多年前,王阳明龙场悟道豁然开朗,致良知,吾心光明!这句话掷地有声、回响千年不绝,开启华夏心学新篇章。为天地立心,为生民立命,为往圣继绝学,为万世开太平。如此沉重伟大的理想,此时此刻王阳明心里终于找到了答案。


一、前言背景

二、客户端发起update SQL更新

三、存储引擎InnoDB-数据缓存池Buffer pool

四、undoLog-记录更新前数据

五、redoLog-记录更新后数据

5.1 redolog的刷盘策略

六、binLog-MySQL server服务逻辑日志

6.1 binlog的刷盘策略

6.2 binLog和redoLog一起完成事务提交

七、后台IO线程更新缓存数据落盘


一、前言背景

    每次看到binLog几个字,让我想起今年LOL S14,熬夜看完BLG2:3痛失冠军比赛,印象最深感觉最可惜的上单Bin哥。之前解说记得说过:天不生TheShy,LPL上单万古无长夜!现如今的Bin哥,个人觉得是Shy哥之后:天不生Bin,LPL上单万古无长夜!能抗能C,还能1 vs N拿到头还不死,这样的团队大核,值得登顶世界第一上单!期待S15,Shy哥回归,与Bin哥的精彩对局。抱歉,扯远了!

    上一篇文章,我们对MySQL整体架构有了初步了解,今天我们深入了解核心存储引擎相关要点,主角就是undoLog、redoLog、binLog日志三宝。通过一条更新sql执行过程,来详细了解这三种日志的生成,以及结合一些故障场景了解他们的意义。掌握底层原理过程,对深入掌握MySQL存储引擎和面试跳槽极其重要!


二、客户端发起update SQL更新

     我们有一条更新SQL,目标是更新id为1的数据name为lading01:

update user set name='lading01' where id =1;

     如下图,SQL从客户端到达MySQL接口、解析器、优化器、存储引擎。接下来存储引擎如何执行更新?


三、存储引擎InnoDB的核心-数据缓存池Buffer pool

     不管是查询sql or 更新sql来到存储引擎,都要应用存储引擎的数据缓存池buffer pool。update sql也是先检查缓存池,看目标数据是否在缓存池里,如果存在,就加锁去更新缓存。如果数据不在buffer pool,就先从磁盘找找到对应数据页加载到缓存池,再加锁更新。buffer pool是核心中的核心,后面会出一篇专门讲里面的数据结构、刷数策略、冷热数据链处理逻辑等内容。

     buffer pool很强大,可以说InnoDB的所有数据缓存都在这。但传统意义,大家喜欢把数据、索引、锁缓存数据作为buffer pool的唯一数据,这种理解划分其实仁者见仁没有对错。为了方便大家理解和分享,今天三宝undo、redo、binlog也单独画缓存图。


四、undoLog-记录更新前数据

     undoLog有的称为回滚日志、撤销日志,或者修改前日志。我更喜欢用【操作前数据日志】来定义undoLog。undoLog的意义,在于用来回滚数据。尤其是事务还没提交,需要做回滚,就可以通过undoLog来回滚。不管是新增insert、还是delete删除、或者update更新,undoLog都可以记录到操作前的数据,确保可以进行有效回滚。

    undoLog,在缓存池中也有自己的缓存,undoLog buffer,最终持久数据默认存储在xx.ibdata文件中。这里具体可以理解为:update sql就记录修改前值,delete删除的话就记录被删除数据信息,而insert新增就生成对应的delete。

    在把id=1数据加载到缓存池后,先把修改前值,写入到undoLog日志。最后更新id=1的数据缓存。步骤如图:

undoLog除了做事务回滚,在MVCC多版本控制起了关键作用。


五、redoLog-记录更新后数据

     在将新值更新到buffer pool后,以及记录数据旧值到undoLog,此时出现了一个问题:磁盘数据和缓存是不一致,磁盘里的数据还没被及时更新。假如其他一切正常,服务器宕机或者MySQL服务异常下线,就导致缓存里的新值无法被记录到磁盘里。

     这时候,redoLog出现了。在经过1、2、3,记录完修改前值,并更新了缓存数据,还需要记录修改后新值的redoLog日志数据。「拉丁解牛说技术,实用至上,坚持用最简洁直白的文字+最少的代码示例分享干货。」

     redoLog的作用和undoLog很像,它是负责支持MySQL异常宕机后,用来恢复修改后未被及时写入磁盘的缓存数据。

image.png

5.1 redolog的刷盘策略

     MySQL高效的读写效率很大一部分在于存储引擎缓存的优秀设计。在数据更新、undo、redoLog的更新,都是先直接更新内存,这样效率非常高。但是这样就需要研发认真考虑,缓存数据什么时候需要刷盘写入磁盘文件。

redoLog从内存更新到磁盘专门有一个参数:【innodb_flush_log_at_trx_commit】控制。具体如下:

innodb_flush_log_at_trx_commit=0: 表示每次事务提交时都只是把 redo log 留在 redo log buffer 。

innodb_flush_log_at_trx_commit=1: 表示每次事务提交时都将 redo log 直接持久化到磁盘,

innodb_flush_log_at_trx_commit=2: 表示每次事务提交时都只是把 redo log 写到系统 page cache,这个缓存大概1s左右刷一次到磁盘。

     面对MySQL宕机,具体分析:

当提交事务后,如果innodb_flush_log_at_trx_commit=0,MySQL宕机了,undoLog丢失,就导致数据丢失。

当提交事务后,如果innodb_flush_log_at_trx_commit=1,MySQL宕机了,undoLog已经写到磁盘,系统恢复后,从redolog恢复最新更新值。

当提交事务后,如果innodb_flush_log_at_trx_commit=2,MySQL宕机了,undoLog由于仅存在系统缓存,如果很不幸,存在os cache数据没来得及刷入磁盘redoLog日志,此时也会出现数据丢失。

     所以,对数据一致性和数据丢失0容忍的业务场景,必须选择innodb_flush_log_at_trx_commit=1。确保事务提交时,redoLog都已经持久化到磁盘存储,确保MySQL服务下线、或者服务器宕机都不会出现数据丢失。


六、binLog-MySQL Server服务逻辑日志

     在了解了undoLog、redoLog两兄弟后,一个用来做回滚、一个用来做数据恢复,承担的数据功能各有不同。而我们常说的MySQL事务确保数据不丢失,很大功劳就是redoLog日志。

如此看来,update sql在数据修改前、后,都得到了很好的保障。为什么还需要binLog? binLog有什么作用?

「拉丁解牛说技术,实用至上,坚持用最简洁直白的文字+最少的代码示例分享干货。」

     MySQL作为一个完整的系统服务,也需要自己的日志。undoLog、redoLog更多是存储引擎在做数据变更前后的日志记录。从整体来说,存储引擎只是MySQL系统的一个组件。而binLog的正是MySQL系统的数据行为逻辑日志。

     binLog内容(全称binary log)是二进制内容,类似日常开发主动打印的log.info日志,比如:MySQL接受update SQL请求,binLog会记录下xx在什么时候,对id=1这行数据进行更新,更新值为lading01,主要用于数据恢复和主从复制。而redo、undoLog属于数据物理数据日志,日志内容类似在磁盘数据页地址0xada421的4kb的数据区xxx,修改了新值xx。

     很明显,binLog是所有MySQL都有的通用逻辑日志,而undo、redoLog日志,属于存储引擎InnoDB的日志,属主不一样,意义格式内容也不一样。

     当更新SQL提交事务,redoLog记录完后,也要记录binLog日志,默认是binLog的数据写到os 缓存,具体如下步骤5:

6.1 binlog的刷盘策略

     MySQL有个参数【sync_binlog】专门用来控制提交事务时binLog的刷盘策略。具体策略如下:

sync_binlog=0,默认就是0,表示每次提交事务都只写到os cache,不 fsync。这种情况如果MySQL服务器突然宕机,存在os cache没来得及被刷到磁盘的,就可能出现binlog日志丢失情况。

sync_binlog=1,表示每次提交事务都会执行 fsync,binLog必须落地到磁盘。也就是事务提交,binLog已经完成持久化到磁盘,数据不会丢失。

sync_binlog=N(N>1) ,表示每次提交事务都 write,但累积 N 个事务后才 fsync。

6.2 binLog和redoLog一起完成事务提交

     在redoLog物理日志落盘、binLog逻辑日志落盘时候,这里有个细节。本次更新写到binlog文件的位置、会同步写到redoLog文件里并加上commit标识在redoLog,表示该事务提交真正完成,如下图第6步骤。这么做的意义是什么呢?

     答案:确保数据层级的日志+服务层的日志,在事务提交时能保持一致。具体分析:

假如在步骤4完成后,系统挂了,由于binLog为落盘,所以本次事务提交不算完成,属于事务提交失败。

假如在步骤5完成后,系统挂了,由于binLog、redoLog都落盘,但是没回写记录commit到redoLog,本次事务不算完成,属于事务提交失败。

假如在步骤6完成后,系统才挂,这时候,redoLog、binLog、以及redoLog记录了commit标识,本次事务得到完整记录,事务提交成功。系统重启后,可以恢复该事务数据。

     基于这个设计,10年前我们在用kafka 0.7、0.8版本的时候,在消费topic数据时,为了在kafka-client记录消费数据的offset,我也参考过这个思想,在落地消费数据的时候,也将offset持久化到磁盘。确保本次消费事务提交前,日志和数据都已经落地。

七、后台IO线程更新缓存数据落盘

      当MySQL的日志三宝都落盘后,缓存池里的最新数据,什么时候落盘?MySQL设计专门的线程负责不定时去把缓存里的最新数据更新到磁盘,这里深入说也比较复杂,今天篇幅有限,等下一篇深入分享。


推荐阅读拉丁解牛相关专题系列(欢迎交流讨论公众号搜:拉丁解牛):

1、JVM进阶调优系列(3)堆内存的对象什么时候被回收?

2、JVM进阶调优系列(2)字节面试:JVM内存区域怎么划分,分别有什么用?

3、JVM进阶调优系列(1)类加载器原理一文讲透

4、JAVA并发编程系列(13)Future、FutureTask异步小王子


相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
5
6
0
106
分享
相关文章
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
141 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
36 16
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
26 4
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
mysql 的ReLog和BinLog区别
MySQL中的重做日志和二进制日志是确保数据库稳定性和可靠性的关键组件。重做日志主要用于事务的持久性和原子性,通过记录数据页的物理修改信息来恢复未提交的事务;而二进制日志记录SQL语句的逻辑变化,支持数据复制、恢复和审计。两者在写入时机、存储方式及配置参数等方面存在显著差异。
112 6
Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
【9月更文挑战第1天】Canal作为一款高效、可靠的数据同步工具,凭借其基于MySQL binlog的增量同步机制,在数据同步领域展现了强大的应用价值
1162 4
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
875 2
【MySQL】根据binlog日志获取回滚sql的一个开发思路
【MySQL】根据binlog日志获取回滚sql的一个开发思路
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
150 2
【赵渝强老师】MySQL的binlog日志文件
MySQL的binlog日志记录了所有对数据库的更改操作(不包括SELECT和SHOW),主要用于主从复制和数据恢复。binlog有三种模式,可通过设置binlog_format参数选择。示例展示了如何启用binlog、设置格式、查看日志文件及记录的信息。
585 6

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多