首先提及一下事务的ACID ：原子性、一致性、隔离性和持久性

隔离性：是由锁实现的

原子性、一致性、和持久性是由 redo log 和undo log 来保证的

Mysql日志主要包括

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

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

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

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

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

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

redo log

redo log 称为重做日志，是储存引擎层（innodb）生成的日志。提供再写入的操作，回复提交事务修改页的操作，用来保证事务持久性，假如说发生宕机，可以进行恢复数据，保证持久性，。他记录的是“物理级别”上的页修改操作，比如页号x，偏移量y，写入了“”ds‘’数据。为了保证数据的可靠性；

undo log 称为回滚日志，也是是储存引擎层（innodb）生成的日志。回滚记录到某个特定的版本，用来保证事务原子性，一致性。主要用于事物的回滚和一致性非锁定读（undo log 会滚到记录某种特定的版本---mvcc，也就是多版本并发控制）。其实现原理借鉴以下图片

他是不断指向上一个日志链条，以此实现回滚。

好处：

redo日志降低了刷盘频率

占用空间非常小（只是储存空间ID、页号、偏移量和需要更新的值）

特点

顺序写入磁盘（每执行一条语句就可能产生redo日志，这些日志是按顺序写入磁盘的）事务执行过程中，redo不断记录，假设一个事务我们插入10万数据，在这个过程，redo 会不断地记录。但是bin log（数据库层产生）不会记录，直到事务提交完成才一次性写入

组成

redo log buffer 和 redo log file

redo log buffer

保存在内存之中，容易丢失

每次启动时后就会申请一大片称之为redo，log buffer的连续空间，然后这款空间再被划分成若干连续的redo log block 。一个 block占512字节

参数设置：innodb_log_buffer_size

默认16MB ，最大值4096M ，最小值1M

redo log file

保存在磁盘中，是最持久的

默认存储当前文件夹下

流程

第1步:先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
第2步:生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值
第3步:当事务commit时，将redo log buffer中的内容刷新到redo log file，对redo log file采用追加写的方式
第4步:定期将内存中修改的数据刷新到磁盘中

redo log 的刷盘策略

其实就是redo log buffer 到 redo log file 的过程

InnoDB给出 innodb_ flush_ .log- at_ _trx_ .commit 参数，该参数控制commit提交事务时，如何将redo log buffer中的日志刷新到redo log file中。它支持三种策略:
●设置为0 :表示每次事务提交时不进行刷盘操作。 (系统默认master thread每隔1s进行一次重做日志的同步) 有可能丢失数据
●设置为1 :表示每次事务提交时都将进行同步,刷盘操作(默认值) 安全性好效率差
●设置为2 :表示每次事务提交时都只把redo log buffer内容写入page cache,不进行同步。由os自己决定什么时候同步到磁盘文件。

总结

Undo log

简介

作用1：回滚数据

undo是逻辑日志，只是将数据库逻辑地回复到原来的样子。所有的修改被逻辑的取消了，但是数据结构和页本身和之前大不相同，

作用2：MVCC

mvcc是通过undo来完成的，当用户读取一条行记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的行版本信息，以此实现非锁定读取

读已提交如何基于ReadView机制实现的

RC级别的核心是每次发起查询都重新生成一个ReadView。第一次查询的时候，发现数据的trx_id在自己的min和max之间和m_ids之中，所以它是一个活跃的事务修改的，并且此时尚未提交，所以它会顺着undo log版本链查找以及提交的事务。第二次查询的时候，重新开启一个新的READ VIEW，发现数据的trx_id不在m_ids中，说明该事务已经提交，所以直接读取数据行的数据。这就是RC级别的实现原理。

可重复读如何基于ReadView实现的

可重复读的核心是只在事务开始时生成一个ReadView，后续再次读的时候，即使事务B提交了，但是事务A它的ReadView还是刚开始事务时的，所以认为B还是活跃的，所以继续沿着undo log版本链查询，读取到始终一样。MySQL的可重复读还解决了幻读，因为新插入的数据记录的trx_id要么大于事务A的max_trx_id，要么在m_ids之中 (而且非本身)所以认为插入的数据记录时不能被读取的。

储存结构

1、回滚段与undo页

InnoDB对undo log的管理采用段的方式，也就是回滚段(rollback segment) 。每个回滚段记录了1024个undo log segment ，而在每个undo log segment段中进行undo页的申请。
●在InnoDB1.1版本之前 (不包括1.1版本) ,只有一个rollback segment, 因此支持同时在线的事务限制为1024。虽然对绝大多数的应用来说都已经够用。
●从1.1版本开始InnoDB支持最大128个rollback segment ,故其支持同时在线的事务限制提高到了
128*1024。

undo页的重用

当我们开启一个事务需要写undo log的时候，就得先去undo log segment中去找到一个空闲的位置，当有空位的时候，就去申请undo页，在这个申请到的undo页中进行undo log的写入。我们知道mysq!默认- -页的大小是16k。为每一个事务分配一个页，是非常浪费的(除非你的事务非常长)，假设你的应用的TPS (每秒处理的事务数目)为1000，那么1s就需要1000个页，大概需要16M的存储，1分钟大概需要1G的存储。如果照这样下去除非MySQL清理的非常勤快，否则随着时间的推移，磁盘空间会增长的非常快，而且很多空间都是浪费的。于是undo页就被设计的可以重用了，当事务提交时，并不会立刻删除undo页。因为重用，所以这个undo页可能混杂着其他事务的undo log。undo log在commit后，会被放到一一个链表中，然后判断undo页的使用空间是否小于3/4，如果小于3/4的话，则表示当前的undo页可以被重用，那么它就不会被回收，其他事务的undo log可以记录在当前undo页的后面。由于undo log是离散的，所以清理对应的磁盘空间时，效率不高。

流程图

undo的版本回滚是基于ReadView机制

bin log

简介

binlog即binary log,二进制日志文件，也叫作变更日志(update log)。它记录了数据库所有执行的DDL和DML等数据库更新事件的语句，但是不包含没有修改任何数据的语句(如数据查询语句select、show等) 。它以事件形式记录并保存在二进制文件中。通过这些信息，我们可以再现数据更新操作的全过程。

应用场景

1、数据恢复：如果MySQL数据库，意外停止，可以通过二进制的文件夹来查看用户执行了哪些操作，对数据库服务器文件做了哪些修改，然后根据二进制文件中的记录来恢复数据库服务器。

2、数据复制： 有数据库的延续性和时效性，master把他的二进制日志传递给slaves来达到master-save数据一致的目的

mysql数据库的数据备份数据备份、主备、主主，主从都离不开binlog

写入机制

bihlog写入时，事务执行过程中,先把日志写到binlog cache ，事务提交的时候，再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开, 所以无论这个事务多大，也要确保一次性写入, 所以系统会给每个线程分配一个块内存作为binlog cache。我们可以通过binlog_ cache_ size 参数控制单个线程binlog cache大小，如果存储内容超过了这个参数，就要暂存到磁盘(Swap) 。主要流程如下

write和fsync的时机，可以由参数sync_ binlog 控制，默认是0。

为0的时候，表示每次提交事务都只write,由系统自行判断什么时候执行fsync。虽然性能得到提升，但是机器宕机，page cache里面的binglog会丢失

为1的时候，表示每次提交事务都会执行fsync，就跟redo log的刷盘流程一样

sync_ binlog可以设置成一个较大的数N，表示每次提交事务都会write但是只有当提交事务的数量到达N的时候才会刷盘。

binlog和redolog对比

●redo log它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于InnoDB存储引擎层产生的。
●而binlog是逻辑日志，记录内容是语句的原始逻辑，类似于“给ID=2这- -行的c字段加1”，属于MySQL Server层。
●虽然它们都属于持久化的保证，但是则重点不同。
redo log让InnoDB存储弓|擎拥有了崩溃恢复能力。
bin log 保证了My$QL集群架构的数据一致性。

redolog 、undolog 和binlog相关推荐

binlog/redolog/undolog？再也不会傻傻分不清楚了
欢迎关注方志朋的博客,回复"666"获面试宝典想和大家聊聊 InnoDB 中的锁机制,那么不可避免的要涉及到 MySQL 的日志系统,binlog.redo log.undo l ...
Mysql日志-RedoLog、UndoLog和BinLog的关系捋顺
一条查询语句的执行过程一般是经过连接器.分析器.优化器.执行器等功能模块,最后到达存储引擎. 那么,一条更新语句的执行流程又是怎样的呢?以及MySQL可以恢复到半个月内任意一秒的状态,这是怎样做到的呢 ...
MySQL之一篇读懂binlog redolog undolog
转自:https://juejin.cn/post/6860252224930070536 日志是mysql数据库的重要组成部分,记录着数据库运行期间各种状态信息.mysql日志主要包括错误日志.查询 ...
MySQL的Redolog/Undolog/binlog日志
Amazon Aurora 故障恢复之降低 DNS 切换对应用影响篇
点击上方入口立即[自由构建探索无限] 一起共赴年度科技盛宴! 1. 前言数据库,尤其是 OLTP 的数据库是应用程序的基石.尽管成熟的数据库通常运行起来都相对稳定,但是否能容忍更多的底层故障,是否 ...
MySQL三大日志——binlog、redoLog、undoLog详解
目录跳转电梯 1. redoLog 1.1 为什么需要redo log 1.2 redo log基本概念 1.3 redo log记录形式 2. binlog 2.1 binlog基本概念 2.2 b ...
(十一)MySQL日志篇之undo-log、redo-log、bin-log.....傻傻分不清！
任何项目都会有日志,MySQL也不例外,而且MySQL更是其中的佼佼者,日志种类繁多,而本篇的目的就是全解MySQL中的各类日志,如撤销日志.错误日志.慢查询日志.中继日志.回滚日志..... 其实日 ...
mysql一个事务多个log_MySQL的两阶段事务提交是否先写binlog再写redolog也可行？
下面是目前的MySQL两阶段提交规则: 事务的两阶段提交 MySQL为了兼容其他非事务引擎的复制,在server服务层引入了binlog,Binlog负责记录所有引擎中的修改操作,也因为如此,bi ...
redolog和binlog 刷盘参数
涉及参数(都是事务提交后的动作参数): redolog:innodb_flush_log_at_trx_commit binlog :sync_binlog binlog_group_commit_s ...

redolog 、undolog 和binlog