你必须了解的Mysql 三大日志

这是小小的第五篇，本篇将会着重说明MySql的三大基本日志。

总览

MySql中的日志是MySql数据的重要组成部分，将会记录着数据库运行期间的各种信息，MySql的日志主要分为错误日志，查询日志，慢查询日志，事物日志，二进制日志。小小将会着重介绍二进制日志和事物日志这三种日志。

二进制日志

二进制日志用于记录数据库执行的写入的查询，不包括查询的信息，以二进制的形式保存在磁盘中，其中binlog是MySql的逻辑日志，由Server层记录，任何存储引擎都会记录二进制日志。二进制日志记录的是以下的内容

逻辑日志：可以简单的理解为记录的就是SQL语句。

物理日志：因为MySql 数据最终保存在数据页中，物理日志记录的就是数据页的变更。

其中二进制日志是通过追加的形式进行写入的，通过一个参数可以设置每个二进制日志的文件的大小，达到给定的值以后，生成新的文件，继续保存日志。

查看是否开启二进制日志

输入命令

show variables like 'log_bin';

查看

查看当前服务器上的所有的二进制日志

输入命令

show master logs;

查看当前二进制文件的状态

show master status;

二进制日志使用场景

在实际应用中，二进制日志主要有两个场景，分别是主从复制和数据恢复。主从复制：再Master端开启Binlog然后再Binlog发送到各个Slave端，Slave端重放binlog达到主从数据的一致性。数据恢复：通过使用mysqlbinlog工具达到数据的恢复。

刷盘时机

对于innoDB存储引擎来说，只有在事物提交的时候才会记录biglog此时记录还在内存中，那么biglog什么时候刷到磁盘中呢，这里，通过mysql的sync_binlog参数设置

这个参数设置如下

0：不去强制要求，由系统自行判断何时写入磁盘；

1：每次commit的时候都要将binlog写入磁盘；

N：每N个事务，才会将binlog写入磁盘。

日志格式

其日志格式有三种，分别为语句的，行的，混合模式的。

基于语句的

每一条都将会忠实的记录。

基于行的

所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。它不记录sql语句上下文相关信息，仅保存哪条记录被修改。

混合模式

两者相互搅在一起。

相关操作

查看日志格式

对日志信息进行查看查看最近的日志

show binlog events

输出日志的详细信息

show binlog events in 'mysql-bin.000003';

截图如下

redo log

此为Mysql日志中的事物日志，为物理日志，用于记录对数据页的物理修改，二不是某一行，或者是怎么样的，主要用来恢复提交后的物理数据页。

区别

在存储引擎上产生，二进制日志优先记录。

二进制日志本质上是sql语句，而erdo log 是数据库中页的修改。

二进制日志只在每次事物提交的时候一次性写入缓存中的文件，redo log 在数据修改的时候，提交的时候，修改的时候，发生事物的时候，都会进行提交。

二进制日志记录的是事物的提交。

事物日志记录的是物理页的情况，具有相关的幂等性。

基本约定

这里在操作数据库的时候，按照如下的约定记录日志。

1. 事务开始时，记录START T

2. 事务修改时，记录（T，x，v），说明事务T操作对象x，x的值为v

3. 事务结束时，记录COMMIT T

undo log 操作

undo log 是把所有没有commit的事物回滚到事物开始前的状态，当系统崩溃的时候，可以借助undo log 进行回滚。使用undo log 如下

1. 记录修改日志时，(T，x，v）中v为x修改前的值，这样才能借助这条日志来回滚；

2. 事务提交后，必须在事务的所有修改（包括记录的修改日志）都持久化后才能写COMMIT T日志；这样才能保证，宕机恢复时，已经COMMIT的事务的所有修改都已经持久化，不需要回滚。

使用undo log 的时事物执行顺序如下

1. 记录START T

2. 记录需要修改的记录的旧值（要求持久化）

3. 根据事务的需要更新数据库（要求持久化）

4. 记录COMMIT T

进行宕机回滚的操作

1. 扫描日志，找出所有已经START,还没有COMMIT的事务。

2. 针对所有未COMMIT的日志，根据undo log来进行回滚。

redo log 原理

redo log是指在回放日志的时候把已经COMMIT的事务重做一遍，对于没有commit的事务按照abort处理，不进行任何操作。

使用redo log时，要求：

1. 记录redo log时，(T,x，v）中的v必须是x修改后的值，否则不能通过redo log来恢复已经COMMIT的事务。

2. 写COMMIT T日志之前，事务的修改不能进行持久化，否则恢复时，对于未COMMIT的操作，可能有数据已经修改，但重放redo log不会对该事务做任何处理，从而不能保证事务的原子性。

使用redo log时事务执行顺序

1. 记录START T

2. 记录事务需要修改记录的新值（要求持久化）

3. 记录COMMIT T（要求持久化）

4. 将事务相关的修改写入数据库

使用redo log重做事务

1. 扫描日志，找到所有已经commit的事物。

2. 对于已经commit的事物，根据redo log重做事物。

在日志中使用checkpoint

1. 在日志中记录checkpoint_start (T1,T2...Tn) (Tx代表做checkpoint时，正在进行还未COMMIT的日志）

2. 将所有已提交的事务的更改进行持久化；

3. 在日志中记录checkpoint_end

根据checkpoint来加速恢复

从后往前，扫描redo log

1. 如果先遇到checkpoint_start,则把T1~Tn以及checkpoint_start之后的所有已经COMMIT的事务进行重做；

2. 如果先遇到checkpoint_end, 则T1~Tn以及前一个checkpoint_start之后所有已经COMMIT的事务进行重做；

这里进行具体的操作顺序为

1. 记录START T

2. 记录修改日志（T，x，v，w）（要求持久化，其中v用于undo，w用于redo）

3. 更新数据库

4. 记录 COMMIT T

处理方式如上

小明菜市场

推荐阅读

●实战 | GitLab + Docker 实现多环境部署

●明晰 | Java序列化与反序列化

●理论 | 三天两夜，万字长文，吃透TCP/IP

●应用 | Redis实现 主从，单例，集群，哨兵，配置应用

●实战 | 后端日志的前世今生