MYSQL学习系列(一)（binlog，redolog，undolog）

MYSQL学习系列(一)（binlog，redolog，undolog）

binlog

1. binlog是二进制文件，该日志会记录全部的数据库表结构变更，及数据变更。相应的，对SELECT和2. SHOW操作不会做记载。
2. 二进制日志包含两类文件：
   • 日志索引文件，文件后缀为.index，该文件用于记录所有的二进制日志文件。
   • 二进制日志文件，文件后缀为.00000*，记录数据库的全部DDL和DML(不含查询语句)语句的事件

     DML（data manipulation language）：
     它们是SELECT、UPDATE、INSERT、DELETE，就象它的名字一样，这4条命令是用来对数据库里的数据进行操作的语言
     DDL（data definition language）：
     DDL比DML要多，主要的命令有CREATE、ALTER、DROP等，DDL主要是用在定义或改变表（TABLE）的结构，数据类型，表之间的链接和约束等初始化工作上，他们大多在建立表时使用
     DCL（Data Control Language）：
     是数据库控制功能。是用来设置或更改数据库用户或角色权限的语句，包括（grant,deny,revoke等）语句。在默认状态下，只有sysadmin,dbcreator,db_owner或db_securityadmin等人员才有权力执行DCL 。

3. MYSQL主从复制就是依靠的binlog。
4. MYSQL的三种工作模式：

   （1）Row level（用到MySQL的特殊功能如存储过程、触发器、函数，又希望数据最大化一直则选择Row模式，我们公司选择的是row）
   　　简介：日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。
   　　优点：能清楚的记录每一行数据修改的细节
   　　缺点：数据量太大
   （2）Statement level（默认）
   　　简介：每一条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行。在主从同步中一般是不建议用statement模式的，因为会有些语句不支持，比如语句中包含UUID函数，以及LOAD DATA IN FILE语句等
   　　优点：解决了 Row level下的缺点，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高新能
   　　缺点：容易出现主从复制不一致
   （3）Mixed（混合模式）
   　　简介：结合了Row level和Statement level的优点，同时binlog结构也更复杂。
   　　作者：彦帧
   链接：https://www.jianshu.com/p/ea666baf0d82
   来源：简书
   著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

---

innodb事务日志包括redo log和undo log。
事务日志的目的：实例或者介质失败，事务日志文件就能派上用场。

---

undo log

undo log指事务开始之前， 在操作任何数据之前,首先将需操作的数据备份到一个地方,undo log是为了实现事务的原子性而出现的产物,在Mysql innodb存储引擎中用来实现多版本并发控制

1. undo log 是回退日志，提供 回滚 操作。
2. undo log用来回滚行记录到某个版本。事务未提交之前，Undo保存了未提交之前的版本数据，Undo中的数据可作为数据旧版本快照供其他并发事务进行快照读。

redo log

redo log指事务中操作的任何数据,将最新的数据备份到一个地方,redo log是为了实现事务的持久性而出现的产物

1. redo log是重做日志，提供前滚操作，
2. redo log不是随着事务的提交而写入的，而是在事务执行的过程中，便开始写入redo中。具体的存储落盘策略可以自定义配置。防止在发生故障的时间节点，尚有脏页未写入磁盘，在重启MySQL服务时，可根据redo log经行重做。从而达到事务的未入磁盘数据进行持久化。

   InnoDB 有 buffer pool（简称bp）。bp 是 物理页 的缓存，对 InnoDB 的任何修改操作都会首先在 bp 的 page 上进行，然后这样的页面将被标记为 dirty 并被放到专门的flush list 上，后续将由专门的刷脏线程阶段性的将这些页面写入磁盘。这样的好处是避免每次写操作都操作磁盘导致大量的随机 IO，阶段性的刷脏可以将多次对页面的修改 merge 成一次IO 操作，同时异步写入也降低了访问的时延。
   然而，如果在 dirty page 还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb 将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是 redo log file。这样的技术推迟了 bp 页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写 redo log 操作的开销（顺序 IO，比随机 IO 快很多），以及数据库启动时恢复操作所需的时间。

undo log/redo log的差异

Undo 记录某 数据 被修改 前 的值，可以用来在事务失败时进行 rollback；
Redo 记录某 数据块 被修改 后 的值，可以用来恢复未写入 data file 的已成功事务更新的数据。
即，
Redo Log 保证事务的持久性
Undo Log 保证事务的原子性（在 InnoDB 引擎中，还用 Undo Log 来实现 MVCC）
比如某一时刻数据库 DOWN 机了，有两个事务，一个事务已经提交，另一个事务正在处理。数据库重启的时候就要根据日志进行前滚及回滚，把已提交事务的更改写到数据文件，未提交事务的更改恢复到事务开始前的状态。即，当数据 crash-recovery 时，通过 redo log 将所有已经在存储引擎内部提交的事务应用 redo log 恢复，所有已经 prepared 但是没有 commit 的 transactions 将会应用 undo log 做 roll back。
假设只有 undo-log：那么就必须保证提交前刷脏完成，否则宕机时有些修改就在内存中丢失了，破坏了持久性。（这样带来了一个问题，那就是前面提到的性能差）
假设只有 redo-log：那么就不能随心所欲地在事务提交前刷脏，即无法支持大事务。（假如、某张表有 100 亿的 8 字节整数数据，就算不考虑其他东西带来的损耗，光 update 整张表至少要消耗 80G 的内存。如前所述，有了 undo-log，就可以随便刷脏。）
层次不同。redo/undo 是 innodb 引擎层维护的，而 binlog 是 mysql server 层维护的，跟采用何种引擎没有关系，记录的是所有引擎的更新操作的日志记录。
记录内容不同。redo/undo 记录的是 每个页/每个数据 的修改情况，属于物理日志+逻辑日志结合的方式（redo log 是物理日志，undo log 是逻辑日志）。binlog 记录的都是事务操作内容，binlog 有三种模式：Statement（基于 SQL 语句的复制）、Row（基于行的复制） 以及 Mixed（混合模式）。不管采用的是什么模式，当然格式是二进制的，
记录时机不同。redo/undo 在 事务执行过程中 会不断的写入，而 binlog 是在 事务最终提交前 写入的。binlog 什么时候刷新到磁盘跟参数 sync_binlog 相关。