MySQL中的日志(redo logundo logbinlog)

Posted 流楚丶格念

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL中的日志(redo logundo logbinlog)相关的知识,希望对你有一定的参考价值。

文章目录

mysql中的日志

一般日志

Mysql 中的日志主要包括:

1、慢查询日志:记录执行时间超过long_query_time的所有查询,方便我们对查询优化

2、通用查询:日志:记录所有连接的起始时间和终止时间,以及连接发送给数据库服务器的所有指令,对我们复原操作的实际场景、发现问题,甚至是对数据库操作的审计都有很大的帮助。

3、查询日志:错误日志:记录MySQL服务的启动、运行或停止MySQL服务时出现的问题,方便我们了解服务器的状态,从而对服务器进行维护。

4、二进制日志(bin log):记录所有更改数据的语句,可以用于主从服务器之间的数据同步,以吸服务器遇到故障时数据的无损失恢复。

5、中继日志:用于主从服务器架构中,从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容,来同步主服务器上的操作。

6、数据定义语句日志:记录数据定义语句执行的元数据操作。

binlog(Binary Log):

二进制日志文件就是常说的binlog。二进制日志记录了MySQL所有修改数据库的操作,然后以二进制的形式记录在日志文件中,其中还包括每条语句所执行的时间和所消耗的资源,以及相关的事务信息

默认情况下,二进制日志功能是开启的,启动时可以重新配置 --log-bin[=file_name] 选项,修改二进制日志存放的目录和文件名称。

重做日志

重做日志用来实现事务的持久性,即事务ACID中的D。

它由两部分组成:

  • 一是内存中的重做日志缓冲(redo log buffer),其是易失的;
  • 二是重做日志文件(redo log file),它是持久的。

InnoDB是事务的存储引擎,它通过Force Log at Commit机制实现事务的持久性,即当事务提交(COMMIT)时,必须先将该事务的所有日志写入到重做日志文件进行持久化,待事务的COMMIT操作完成才算完成。

这里的日志是指重做日志,在InnoDB存储引擎中,由两部分组成,即redo log和undo log。

重做日志记录了事务的行为,可以很好地通过其对页进行“重做”操作。但是事务有时还需要进行回滚操作,这时就需要undo。

因此在对数据库进行修改时,InnoDB存储引擎不但会产生redo,还会产生一定量的undo。这样如果用户执行的事务或语句由于某种原因失败了,又或者用户用一条ROLLBACK语句请求回滚,就可以利用这些undo信息将数据回滚到修改之前的样子。

redo log 与 undo log概念

redo log

redo log 称为重做日志 ,是储存引擎层(innodb)生成的日志。

提供再写入的操作,回复提交事务修改页的操作,用来保证事务持久性,假如说发生宕机,可以进行恢复数据,保证持久性。他记录的是“物理级别”上的页修改操作,比如页号x,偏移量y,写入了“”ds‘’数据。为了保证数据的可靠性;

undo log

undo log 称为回滚日志,也是是储存引擎层(innodb)生成的日志。

回滚记录到某个特定的版本,用来保证事务原子性,一致性。主要用于事物的回滚 和 一致性非锁定读(undo log 会滚到记录某种特定的版本—mvcc,也就是多版本并发控制)。

redo log 与 undo log区别

redo存放在重做日志文件中,与redo不同,undo存放在数据库内部的一个特殊段(segment)中,这个段称为undo段(undo segment),undo段位于共享表空间内。

redo log用来保证事务的持久性,undo log用来帮助事务回滚及MVCC的功能

redo log基本上都是顺序写的,在数据库运行时不需要对redo log的文件进行读取操作。而undo log是需要进行随机读写的。

redo log 与 undo log原理

redo log

redo log 的作用主要是实现 ACID 中的持久性,保证提交的数据不丢失

  • 它记录了事务提交的变更操作,服务器意外宕机重启时,利用 redo log 进行回放,重新执行已提交的变更操作
  • 事务提交时,首先将变更写入 redo log,事务就视为成功。至于数据页(表、索引)上的变更,可以放在后面慢慢做
    • 数据页上的变更宕机丢失也没事,因为 redo log 里已经记录了
    • 数据页在磁盘上位置随机,写入速度慢,redo log 的写入是顺序的速度快

它由两部分组成,内存中的 redo log buffer,磁盘上的 redo log file

  • redo log file 由一组文件组成,当写满了会循环覆盖较旧的日志,这意味着不能无限依赖 redo log,更早的数据恢复需要 binlog

  • buffer 和 file 两部分组成意味着,写入了文件才真正安全,同步策略由参数 innodb_flush_log_at_trx_commit 控制,同步策略如下:

    策略参数说明
    0每隔 1s 将日志 write and flush 到磁盘
    1每次事务提交将日志 write and flush(默认值)
    2每次事务提交将日志 write,每隔 1s flush 到磁盘,意味着 write 意味着写入操作系统缓存,如果 MySQL 挂了,而操作系统没挂,那么数据不会丢失

undo log

  • 回滚数据,以行为单位,记录数据每次的变更,一行记录有多个版本并存
  • 支持多版本并发控制(MVCC),即快照读(也称为一致性读),让查询操作可以去访问历史版本

回滚流程如何如下所示:

  1. 每个事务会按照开始时间,分配一个单调递增的事务编号 trx id
  2. 每次事务的改动都会以行为单位记入回滚日志,包括当时的事务编号,改动的值等
  3. 查询操作,事务编号大于自己的数据是不可见的,事务编号小于等于自己的数据才是可见的
    • 例如图中红色事务看不到 trx id=102 以及 trx id=101 的数据,只有 trx id=99 的数据对它可见

以上是关于MySQL中的日志(redo logundo logbinlog)的主要内容,如果未能解决你的问题,请参考以下文章

对Mysql中redo logundo logbinlog深入理解

对Mysql中redo logundo logbinlog深入理解

MySQL的redo logundo logbinlog

MySQL系列之日志汇总:redo logundo logbinlogerrorlogslow query loggeneral logrelay log

MySQL 进阶 InnoDB引擎 -- 逻辑存储结构架构(内存结构磁盘结构后台线程)事务原理(事务基础redo logundo logMVCC多版本并发控制:版本链 ReadView)

Mysql日志---redo