MySQL日志

概述

日志是mysql数据库的重要组成部分，记录着数据库运行期间各种状态信息。mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。作为开发，重点需要关注的是二进制日志(bin log)和事务日志(包括redo log和undo log)。

物理日志和逻辑日志

• 物理日志：通俗的讲，就是只有”我”自己可以使用，别人无法共享“我的”物理格式，私有化。
• 逻辑日志：可以给别的引擎使用，是所有引擎共享的。

日志模块:redo log

redo log 产生背景

说mysql日志redo log，先说一个故事。从前有一家酒馆，酒馆老板常备着一个粉板，专门记着客人的赊账记录，也是他的法宝之一。如果赊账的人不多，他可以在粉板上记录下赊账的人和账目。如果赊账人多的话，由于粉板的空间大小有限，所以他又需要额外准备一本账本，专门记录所有赊账的账目。
如果有人要赊账的话，一般老板有两种做法：

• 打开账本，找到赊账人的记录，进行追加赊账记录
• 先把赊账人的记录写到粉板上，待客流量少的时刻，再更新到赊账账目上

如果老板使用第一种方法的话，每当有人要赊账的话，首先他需要打开厚厚的账本，一页一页查找该顾客的姓名，然后进行登记。你们想啊，如果赊账的人不多，老板找赊账人的记录轻松点，如果赊账本有好几本的话，一本一本的找，老板看的都头疼。
方案一的过程想想都头大。相比第二种方案，对老板就相对轻松点，老板只需要把赊账人的信息写在粉板上，待客流量低的时候，再更新到赊账本上。
同样，mysql里也有同样的问题，如果每一次数据的操作都写入磁盘中，首先磁盘先要找到对应的记录，然后再更新，整个过程io成本，查找成本比较高。所以，mysql为了提高性能，使用了类似老板粉板方式，先把更新数据结果存储到某个地方，待空闲时再写入磁盘中。
而mysql把更新结果存储的地方，就是redo log

redo log 基本概念

redo log是InnoDB存储引擎层的日志，又被称为重写日志，用来记录事务操作的变化，记录的是数据修改之后的值，不管事务提交是否成功，都会被记录下来。
而这种先写日志，后写磁盘的技术就是mysql里面经常提及到的WAL(Write Ahead Logging)技术。
具体的来说，就是当有一条记录需要更新的时候，InnoDB引擎会把记录优先更新到redo log（粉板）里面，并更新内存，这样更新操作就完成了。同时，InnoDB引擎会在空闲的时间将redo log中的记录存储到磁盘上。
重做日志用来实现事务的持久性，即事务ACID中的D。其由两部分组成，一是内存中的重做日志缓冲（redo log buffer），其是易失的；二是重做日志文件（redo log file），其是持久的。

redo log 记录方式

由于redo log记录的是数据页的变更，而这种记录是没有必要永久保存的，因此redo log实现上采用来大小固定，循环写入的方式，当记录写到末尾时，又会从头开始写，如下图所示。

如图所示，write pos是当前记录的位置，一边写一边后移，写到4号文件末尾就回到1号文件开头。check point是当前要把记录写入到数据文件的位置，也是后移并且循环的。
如果和上面老板粉板场景结合起来描述的话，write pos就是老板在粉板上顺序写入赊账人记录位置，对于mysql来说，write pos后移；而check point就是老板把粉板上记录写入到赊账本上的位置，当老板写入到赊账本上后，就会把粉板上该记录擦除掉，对于mysql来说，check point后移。

redo log 使用场景

• 用于系统崩溃后恢复(crash-safe)

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

日志模块:bin log

bin log 基本概念

bin（Binary Log） log是mysql数据库service层的，是所有存储引擎共享的日志模块，它用于记录数据库执行的写入性操作，也就是在事务commit阶段进行记录，以二进制的形式保存于磁盘中。
二进制日志记录了MySQL所有修改数据库的操作，然后以二进制的形式记录在日志文件中，其中还包括每条语句所执行的时间和所消耗的资源，以及相关的事务信息。

• bin log是逻辑日志，并且由mysql数据库的service层执行，也就是说使用所有的存储引擎数据库都会记录bin log日志。
• bin log是以追加的方式进行写入的，可以通过 max_binlog_size 参数设置bin log文件大小，当文件大小达到某个值时，会生成新的文件来保存日志。

bin log 刷盘机制

对于InnoDB引擎而言，在每次事务commit提交时才会记录bin log日志，此时记录仍然在内存中，那么什么时候存储到磁盘中呢？mysql通过 sync_binlog 参数控制bin log刷盘时机。

取值范围：0～N：

• 0：不去强求，由系统自行判断何时写入磁盘；
• 1：每次事务commit的时候都要将bin log写入磁盘；
• N：每N个事务commit，才会将bin log写入磁盘；

sync_binlog 参数建议设置为1，这样每次事务commit时就会把bin log写入磁盘中，这样也可以保证mysql异常重启之后bin log日志不会丢失。

bin log 使用场景

在实际场景中， bin log 的主要场景有两点，一点是主从复制，另一点是数据恢复

• 主从复制：在master端开启 bin log ，然后将 bin log 发送给各个slaver端，slaver端读取 bin log 日志，从而使得主从数据库中数据一致
• 数据恢复：通过 bin log 获取想要恢复的时间段数据

日志模块:undolog

undo log 基本概念

undo log 是回滚日志，是记录每条数据的所有版本，比如 update 语句，那么它首先会将该条记录的数据记录到undo log日志中，并且将最新版本的roll_pointer指针指向上一个版本，这样就可以形成当前记录的所有版本，这也是MVCC的实现机制。
实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。InnoDB实现回滚靠的是undo log，当事务对数据库进行修改时，InnoDB会生成对应的undo log。如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作。对于insert，回滚时会执行delete。对于delete，回滚时会执行insert。对于update，回滚时则会执行相反的update，把数据改回去。
在对数据库进行修改时，InnoDB存储引擎不但会产生redo，还会产生一定量的undo。这样如果用户执行的事务或语句由于某种原因失败了，又或者用户用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。
redo存放在重做日志文件中，与redo不同，undo存放在数据库内部的一个特殊段（segment）中，这个段称为undo段（undo segment），undo段位于共享表空间内。

每一行 undo log 可以简化为下图所示的结构

undo log 使用场景

• MVCC多版本控制中使用undo log

总结