mysql三大日志-binlog、redo log和undo log
日志是mysql
数据库的重要组成部分,记录着数据库运行期间各种状态信息。mysql
日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发,我们重点需要关注的是二进制日志(binlog
)和事务日志(包括redo log
和undo log
),本文接下来会详细介绍这三种日志。
binlog
binlog
用于记录数据库执行的写入性操作(不包括查询)信息,以二进制的形式保存在磁盘中。binlog
是mysql
的逻辑日志,并且由Server
层进行记录,使用任何存储引擎的mysql
数据库都会记录binlog
日志。
逻辑日志:可以简单理解为记录的就是sql语句。
物理日志:因为
mysql
数据最终是保存在数据页中的,物理日志记录的就是数据页变更。
binlog
是通过追加的方式进行写入的,可以通过max_binlog_size
参数设置每个binlog
文件的大小,当文件大小达到给定值之后,会生成新的文件来保存日志。
binlog使用场景
在实际应用中,binlog
的主要使用场景有两个,分别是主从复制和数据恢复。
-
主从复制:在
Master
端开启binlog
,然后将binlog
发送到各个Slave
端,Slave
端重放binlog
从而达到主从数据一致。 -
数据恢复:通过使用
mysqlbinlog
工具来恢复数据。
binlog刷盘时机
对于InnoDB
存储引擎而言,只有在事务提交时才会记录biglog
,此时记录还在内存中,那么biglog
是什么时候刷到磁盘中的呢?mysql
通过sync_binlog
参数控制biglog
的刷盘时机,取值范围是0-N
:
- 0:不去强制要求,由系统自行判断何时写入磁盘;
- 1:每次
commit
的时候都要将binlog
写入磁盘; - N:每N个事务,才会将
binlog
写入磁盘。
从上面可以看出,sync_binlog
最安全的是设置是1
,这也是MySQL 5.7.7
之后版本的默认值。但是设置一个大一些的值可以提升数据库性能,因此实际情况下也可以将值适当调大,牺牲一定的一致性来获取更好的性能。
binlog日志格式
binlog
日志有三种格式,分别为STATMENT
、ROW
和MIXED
。
在
MySQL 5.7.7
之前,默认的格式是STATEMENT
,MySQL 5.7.7
之后,默认值是ROW
。日志格式通过binlog-format
指定。
-
STATMENT
基于SQL
语句的复制(statement-based replication, SBR
),每一条会修改数据的sql语句会记录到binlog
中。优点:不需要记录每一行的变化,减少了binlog
日志量,节约了IO
, 从而提高了性能;缺点:在某些情况下会导致主从数据不一致,比如执行sysdate()
、slepp()
等。 -
ROW
基于行的复制(row-based replication, RBR
),不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了。优点:不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题;缺点:会产生大量的日志,尤其是alter table
的时候会让日志暴涨 -
MIXED
基于STATMENT
和ROW
两种模式的混合复制(mixed-based replication, MBR
),一般的复制使用STATEMENT
模式保存binlog
,对于STATEMENT
模式无法复制的操作使用ROW
模式保存binlog
redo log
为什么需要redo log
我们都知道,事务的四大特性里面有一个是一致性,具体来说就是只要事务提交成功,那么对数据库做的修改就被永久保存下来了,不可能因为任何原因再回到原来的状态。那么mysql
是如何保证一致性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题,主要体现在两个方面:
- 因为
Innodb
是以页
为单位进行磁盘交互的,而一个事务很可能只修改一个数据页里面的几个字节,这个时候将完整的数据页刷到磁盘的话,太浪费资源了! - 一个事务可能涉及修改多个数据页,并且这些数据页在物理上并不连续,使用随机IO写入性能太差!
因此mysql
设计了redo log
,具体来说就是只记录事务对数据页做了哪些修改,这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
redo log基本概念
redo log
包括两部分:一个是内存中的日志缓冲(redo log buffer
),另一个是磁盘上的日志文件(redo log file
)。mysql
每执行一条DML
语句,先将记录写入redo log buffer
,后续某个时间点再一次性将多个操作记录写到redo log file
。这种先写日志,再写磁盘的技术就是MySQL
里经常说到的WAL(Write-Ahead Logging)
技术。
在计算机操作系统中,用户空间(user space
)下的缓冲区数据一般情况下是无法直接写入磁盘的,中间必须经过操作系统内核空间(kernel space
)缓冲区(OS Buffer
)。因此,redo log buffer
写入redo log file
实际上是先写入OS Buffer
,然后再通过系统调用fsync()
将其刷到redo log file
中,过程如
mysql
支持三种将redo log buffer
写入redo log file
的时机,可以通过innodb_flush_log_at_trx_commit
参数配置,各参数值含义如下:
参数值 |
含义 |
---|---|
0(延迟写) |
事务提交时不会将redo log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到redo log file中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。 |
1(实时写,实时刷) |
事务每次提交都会将redo log buffer中的日志写入os buffer并调用fsync()刷到redo log file中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO的性能较差。 |
2(实时写,延迟刷) |
每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到redo log file。 |
redo log记录形式
前面说过,redo log
实际上记录数据页的变更,而这种变更记录是没必要全部保存,因此redo log
实现上采用了大小固定,循环写入的方式,当写到结尾时,会回到开头循环写日志。如下图:
同时我们很容易得知,在innodb中,既有redo log
需要刷盘,还有数据页
也需要刷盘,redo log
存在的意义主要就是降低对数据页
刷盘的要求。在上图中,write pos
表示redo log
当前记录的LSN
(逻辑序列号)位置,check point
表示数据页更改记录刷盘后对应redo log
所处的LSN
(逻辑序列号)位置。write pos
到check point
之间的部分是redo log
空着的部分,用于记录新的记录;check point
到write pos
之间是redo log
待落盘的数据页更改记录。当write pos
追上check point
时,会先推动check point
向前移动,空出位置再记录新的日志。
启动innodb
的时候,不管上次是正常关闭还是异常关闭,总是会进行恢复操作。因为redo log
记录的是数据页的物理变化,因此恢复的时候速度比逻辑日志(如binlog
)要快很多。重启innodb
时,首先会检查磁盘中数据页的LSN
,如果数据页的LSN
小于日志中的LSN
,则会从checkpoint
开始恢复。还有一种情况,在宕机前正处于checkpoint
的刷盘过程,且数据页的刷盘进度超过了日志页的刷盘进度,此时会出现数据页中记录的LSN
大于日志中的LSN
,这时超出日志进度的部分将不会重做,因为这本身就表示已经做过的事情,无需再重做。
redo log与binlog区别
redo log |
binlog |
|
---|---|---|
文件大小 |
redo log的大小是固定的。 |
binlog可通过配置参数max_binlog_size设置每个binlog文件的大小。 |
实现方式 |
redo log是InnoDB引擎层实现的,并不是所有引擎都有。 |
binlog是Server层实现的,所有引擎都可以使用 binlog日志 |
记录方式 |
redo log 采用循环写的方式记录,当写到结尾时,会回到开头循环写日志。 |
binlog 通过追加的方式记录,当文件大小大于给定值后,后续的日志会记录到新的文件上 |
适用场景 |
redo log适用于崩溃恢复(crash-safe) |
binlog适用于主从复制和数据恢复 |
由binlog
和redo log
的区别可知:binlog
日志只用于归档,只依靠binlog
是没有crash-safe
能力的。但只有redo log
也不行,因为redo log
是InnoDB
特有的,且日志上的记录落盘后会被覆盖掉。因此需要binlog
和redo log
二者同时记录,才能保证当数据库发生宕机重启时,数据不会丢失。
undo log
数据库事务四大特性中有一个是原子性,具体来说就是 原子性是指对数据库的一系列操作,要么全部成功,要么全部失败,不可能出现部分成功的情况。实际上,原子性底层就是通过undo log
实现的。undo log
主要记录了数据的逻辑变化,比如一条INSERT
语句,对应一条DELETE
的undo log
,对于每个UPDATE
语句,对应一条相反的UPDATE
的undo log
,这样在发生错误时,就能回滚到事务之前的数据状态。同时,undo log
也是MVCC
(多版本并发控制)实现的关键。
For Example
一条更新语句执行的顺序
update T set c=c+1 where ID=2;
- 执行器先找引擎取 ID=2 这一行。ID 是主键,引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中,就直接返回给执行器;否则,需要先从磁盘读入内存,然后再返回。
- 执行器拿到引擎给的行数据,把这个值加上 1,比如原来是 N,现在就是 N+1,得到新的一行数据,再调用引擎接口写入这行新数据。
- 引擎将这行新数据更新到内存中,同时将这个更新操作记录到 redo log 里面,此时 redo log 处于 prepare 状态。然后告知执行器执行完成了,随时可以提交事务。
- 执行器生成这个操作的 binlog,并把 binlog 写入磁盘。
- 执行器调用引擎的提交事务接口,引擎把刚刚写入的 redo log 改成提交(commit)状态,更新完成。
参考
- juejin.im/post/684490…
- www.cnblogs.com/f-ck-need-u…
- www.cnblogs.com/ivy-zheng/p…
- yq.aliyun.com/articles/59…
- www.jianshu.com/p/5af73b203…
- www.jianshu.com/p/20e10ed72…
- 一次数据库宕机问题的分析(r6笔记第5天)
- PWN学习之house of系列(一)
- 清理session的小插曲(二) (r6笔记第4天)
- 3.训练模型之在GPU上训练的环境安装
- 深度学习对话系统实战篇 -- 简单 chatbot 代码实现
- pangrank算法--PageRank算法并行实现
- 刷爆朋友圈的 deepfakes 视频人物换脸是怎样炼成的?
- 干货 | ElasticSearch相关性打分机制
- FCN 的简单实现
- 2.运行一个demo
- ROWNUMBER() OVER( PARTITION BY COL1 ORDER BY COL2)/ ROWNUMBER() OVER( PARTITION BY COL1 ORDER BY CO
- 干货 | 前端常用的通信技术
- TP-LINK WR941N路由器研究
- ORA-01113问题的简单分析(r6笔记第3天)
- MySQL 教程
- MySQL 安装
- MySQL 管理与配置
- MySQL PHP 语法
- MySQL 连接
- MySQL 创建数据库
- MySQL 删除数据库
- MySQL 选择数据库
- MySQL 数据类型
- MySQL 创建数据表
- MySQL 删除数据表
- MySQL 插入数据
- MySQL 查询数据
- MySQL where 子句
- MySQL UPDATE 查询
- MySQL DELETE 语句
- MySQL LIKE 子句
- mysql order by
- Mysql Join的使用
- MySQL NULL 值处理
- MySQL 正则表达式
- MySQL 事务
- MySQL ALTER命令
- MySQL 索引
- MySQL 临时表
- MySQL 复制表
- 查看MySQL 元数据
- MySQL 序列 AUTO_INCREMENT
- MySQL 处理重复数据
- MySQL 及 SQL 注入
- MySQL 导出数据
- MySQL 导入数据
- MYSQL 函数大全
- MySQL Group By 实例讲解
- MySQL Max()函数实例讲解
- mysql count函数实例
- MYSQL UNION和UNION ALL实例
- MySQL IN 用法
- MySQL between and 实例讲解
- redis 入门(一)——Linux环境安装测试以及基本命令演示
- 大型项目技术栈第五讲 富文本编辑器
- weblogic 11g StuckThreadMaxTime 问题解决 以及 线程池、数据库连接池参数调优
- 大型项目技术栈第九讲 kaptcha的使用
- 大型项目技术栈第十讲 日志与性能监控
- Mybatis系列第三讲 Mybatis使用详解(1)
- Maven系列第二讲 安装、配置、mvn运行过程详解
- Maven第六讲 生命周期详解 高手必备!
- 鸿蒙 Ability 讲解(页面生命周期、后台服务、数据访问)
- Maven 项目第七讲 Maven插件
- weblogic Schema validation schemaValidationEnabled=false 启动报错解决
- redis 反序列化deserialize异常问题解决
- redis 入门(二)——maven4.0 + Jedis2.9.0 + redis3.2.6 实战
- spring boot 启动报错Log4j2 could not find a logging implementation 解决
- spring boot 启动 NoClassDefFoundError: org/springframework/core/ErrorCoded 报错