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),即快照读(也称为一致性读),让查询操作可以去访问历史版本
回滚流程如何如下所示:
- 每个事务会按照开始时间,分配一个单调递增的事务编号 trx id
- 每次事务的改动都会以行为单位记入回滚日志,包括当时的事务编号,改动的值等
- 查询操作,事务编号大于自己的数据是不可见的,事务编号小于等于自己的数据才是可见的
- 例如图中红色事务看不到 trx id=102 以及 trx id=101 的数据,只有 trx id=99 的数据对它可见
以上是关于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)