标签:http ima master 否则 永久 ras space format 异常
我们都清楚日志是mysql的一个重要组成部分,记录着数据库运行期间各种状态信息。而Mysql日志又分为错误日志、查询日志、慢查询日志、二进制日志(binlog)和事务日志(redo log、undo log)。其中在我们开发中聊的比较多的就是二进制日志(binlog)和事务日志(redo log、undo log)。其实慢查询日志也是我们开发中比较常见的日志,常用于sql优化。本文主要介绍binlog、redo log、undo log三种日志
首先,我们先来了解一下mysql中的专业名词,看到一篇InfoQ的文章介绍的还不错,那么直接引入文章的截图:
这些名词的话在后面的文章中可能会出现,这里先做一个了解。
二进制日志:binary log。简称binLog。记录了对Mysql数据库执行更改的所有操作,但是不包括SELECT 和 SHOW这类操作。以二进制的形式保存在磁盘中。是属于Mysql Server层记录,任何存储引擎的 mysql 数据库都会记录binlog日志。并且binlog 还是 mysql 的逻辑日志
逻辑日志:可以简单理解为记录的就是sql语句
物理日志:mysql 数据最终是保存在数据页的,物理日志记录的就是数据页变更
binlog 是通过追加的方式进行写入的,可以通过max_binlog_size参数设置每个binlog文件的大小,当文件大小达到max_binlog_size后,会生成新的二进制日志文件来保存。从Mysql5.0后默认值1073741824(1G)
binlog 的主要使用场景有两个,分别是 主从复制 和 数据恢复
主从复制:在 Master 端开启 binlog,然后将 binlog 推送到各个 Slave 从端,Slave 端重放 binlog 从而达到主从数据一致
数据恢复:通过使用 mysqlbinlog 工具来恢复数据
binlog 大致记录过程是将所有未提交(uncommitted)的二进制日志写入到 binlog buffer中,等该事务提交(committed)时,然后通过刷盘时机,控制刷入 OS Buffer,控制 fsync() 进行写入 Binlog File 日记文件磁盘的过程。
对于 binlog, MYSQL 是通过参数 sync_binlog 参数来控制刷盘时机,取值范围是 0-N:
可以看出当 sync_binlog = 1时,数据是最安全的。这也是MySQL 5.7.7之后的版本的默认值。但是这样的话可以会牺牲一定的性能来保证数据的一致性。
binlog 日志有三种格式,分别为 STATMENT、ROW 和 MIXED
在MYSQL 5.7.7 之前,默认的格式是 STATMENT,MySQL 5.7.7 之后,默认值是 ROW, 日志格式可以通过binlog-format 指定
我们都知道,事务有一个特性叫做 持久性。也就是事务提交成功,那么对数据库做的修改就被永久保存下来,不可能因为任何原因再回到原来的状态。
那么,mysql是如何保证一致性的呢?
最简单的办法就是每次事务提交成功,将该事务涉及修改的数据页全部刷新到磁盘。但是这么做会有严重的性能问题,主要体现在下面两个方面:
因此 mysql 设计了 redo log, 具体来说就是只记录事务对数据页做了哪些修改,这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
Redo log 是重做日志,属于 InnoDB储存引擎的日志。是物理日志,日志记录的内容是数据页的更改,这个页"做了什么改动"。如:add xx记录 to Page1,向数据页Page1增加一个记录。
redo log 包括两部分:一个是内存中的日志缓冲(redo log buffer),其是易失的。二是重做日志文件(redo log file),其是持久的。
mysql为了保证 Binlog 和 Redo log 数据的一致性,采用了两阶段提交
可以看到将 redo log 的写入拆成了两个步骤:prepare 和 commit两个阶段
为什么需要采用"两阶段提交"呢?
这里假设不采用"两阶段提交"的话,写入完 redo log,接着写binlog时,这时候数据库崩溃,这时候 binlog 里面就没有记录这个语句。但是 redo log里面会保存这条 c的值是1的记录,数据库崩溃我们也是可以通过redo log的日志将数据恢复过来。如果我们需要备份日志的时候,存起来的 binlog 没有这条语句,需要用这个 binlog 来恢复临时库的话,由于这个语句的 binlog 丢失,这个临时库就会少了这一次更新,恢复出来的这一行 c 的值就是 0,与原库的值不同。所以我们需要保证redo log 跟 binlog 数据一致性
只有在 redo log 状态为 prepare 时,才会去检查 binlog 是否存在,否则只校验 redo log 是否是 commit 就可以啦。怎么检查 binlog:一个完整事务 binlog 结尾有固定的格式。
在计算机操作系统中,用户空间(User Space)下的缓冲区数据一般情况下是无法直接写入磁盘的,中间必须经过操作系统内核空间( kernel space )缓冲区( OS buffer)
因此,redo log每次先写入 redo log buffer中,然后通过刷盘时机,将 redo log buffer 的数据写入 redo log file,写入 redo log file 实际上是先写入 OS Buffer,然后再通过系统调用 fsync() 将其刷到 redo log file中,大致过程:
mysql 通过参数 innodb_flush_log_at_trx_commit 来控制刷盘时机,取值是0、1和2三种值。
前面说过,redo log 实际上记录数据页的变更,而这种变更记录是没必要一直保存,因此 redo log 实现上采用了大小固定,循环写入的方式,当写到结尾时,会回到开头循环写日志。如下图:
上图是日志磁盘的 Redo log 环形设计图(从头开始写,写到结束又从头开始写~循环)。write pos 和 check point 是两个指针,write pos 表示 redo log 当前记录的 LSN(日志逻辑序列号(占用8字节))位置,check point 表示数据页更改记录刷盘后对应 redo log 所处的 LSN(日志逻辑序列号)位置。
write pos 到 check point 之间的部分(图中绿色的部分),用于记录新的记录; check point 到 write pos 之间是 redo log 待落盘的数据页更改记录。每次写入,write pos 指针会顺时针推进,当 write pos追上check point 时,会先推动 check point 向前移动,空出位置再记录新的日志
启动 innodb 的时候,不管上次是正常关闭还是异常关闭,总是会进行恢复操作。因为 redo log 记录的是数据页的物理变化,因此恢复的时候速度比逻辑日志(如 binlog )要快很多。
重启 innodb 时,首先会检查磁盘中数据页的 LSN,如果数据页的 LSN 小于 redo log 日志中的 LSN,则会从 checkpoint 开始恢复。
还有一种情况,在宕机前正处于 checkpoint 的刷盘过程,且数据页的刷盘进度超过了日志页的刷盘进度,此时会出现数据页中记录的 LSN 大于 redo log 日志中的 LSN,这时超出日志进度的部分将不会被重做,因为这本身就表示已经做过的事情,无需再重做
?
redo log 和 binlog 有一个很大的区别就是,一个是循环写,一个是追加写。也就是说 redo log 只会记录未刷盘的日志,已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。binlog 是追加日志,保存的是全量日志。
当数据库 crash 后,想要恢复未刷盘但已经写入 redo log 和 binlog 的数据,binlog 是无法恢复的。虽然 binlog 拥有全量的日志,但没有一个标志让 innodb 判断哪些数据已经刷盘,哪些数据还没有
举个例子, binlog 记录了两条日志:
1. 给 ID = 2 这一行的 c 字段加1
2. 给 ID = 2 这一行的 c 字段加2
在记录1刷盘后,记录2未刷盘时,数据库 crash。重启后,只通过 binlog 数据库无法判断这两条记录哪条已经写入磁盘,哪条没有写入磁盘,不管是两条都恢复至内存,还是都不恢复,对 ID=2 这行数据来说,都不对
但 redo log 不一样,只要刷入磁盘的数据,都会从 redo log 中抹掉,数据库重启后,直接把 redo log 中的数据都恢复至内存就可以了。这就是为什么 redo log 具有 crash-safe 的能力,而 binlog 不具备
针对问题1我们知道只有 binlog 日志,没有 redo log 是不能做到故障恢复的。那么针对只有 redo log日志,没有 binlog 日志,这也是不行的,因为 redo log 是 innodb 持有的,且日志上的记录落盘后会被抹掉。因此需要 binlog 和 redo log 两者同时记录,才能保证当数据库发生宕机重启时,数据不会丢失。
我们都知道事务四大特性中有一个是原子性,具体来说就是 原子性是指对数据库的一系列操作,要么全部成功,要么全部失败,不可能出现部分成功的情况
实际上,原子性 底层就是通过 undo log 实现的。undo log 主要记录了数据的逻辑变化,比如一条INSERT 语句,对应着有一条的DELETE的undo log,对于每个UPDATE 语句,对应一条相反的 UPDATE 的 undo log,这样在发生错误时,就能回滚到事务之前的数据状态
undo log 跟 redo log 是属于innodb 引擎的日志
undo log 的记录过程的话跟 redo log 过程差不多,都是先记录到 Log Buffer 中,然后通过刷盘时机将 buffer 中的日志 刷新到 undo log file 中。但是对于 undo log 没找到对应的刷盘参数设计
前面主要介绍了 binlog、redo log、undo log三种日志。binlog是属于mysql Server层的,属于整个mysql的,而redo log、undo log是属于innodb存储引擎独有的,redo log、undo log是事务日志,binlog是二进制日志负责记录对mysql数据库有修改的sql操作。其中还有难懂的点就是redo log进行容灾恢复的过程LSN(日志逻辑序列号)的比较,里面并不简简单单就是我列举的那样,因为篇幅有限,这里就没做具体的详解了,只列举了一个大概的比较过程。
MYSQL三大日志-binlog、redo log、undo log
标签:http ima master 否则 永久 ras space format 异常
原文地址:https://www.cnblogs.com/semi-sub/p/14225047.html