数据库数据库日志——binlog、redo log、undo log扫盲

数据库数据库日志——binlog、redo log、undo log扫盲

日志是数据库中比较重要的组成部分，很多核心的功能必须依靠日志才能完成。

该篇文章简要介绍了binlog、redo log与undo log，能够在一定程度上拓宽对mysql日志的整体认识。

---

binlog

又称归档日志，由Server层实现与记录，因此对任何引擎都有效。

binlog是一种只记录对表中数据以及对表结构产生更改操作的二进制文件，比如有insert、update、delete、create table、alter table等操作，不记录select、show，因为这些操作不会产生任何更改。不过就算一个update未产生数据变化，也是会被记录进去的。

你可以理解binlog是直接记录sql语句，或者说记录原始sql逻辑，因此binlog属于逻辑日志。

binlog是追加写入的，一个文件写满，会重新创建一个文件继续写，文件名称是mysql-bin.xxxxxx，例如myql-bin.000001，序号部分会递增。

binlog的格式

binlog有三种格式，可以通过binlog-format来设定

STATEMENT

直接记录操作的sql语句，例如update student set name='tom' where id=1;

优点：

这种格式的binlog，可以直接进行阅读。

不记录具体的行数据，日志量不会很大，性能较优。

缺点：

当binlog用于主从之间的复制时，如果当前的sql语句为随机函数rand()、当前日期now()等，在重现之后具有不同的值，具有歧义性，可能会造成复制后数据不一致。

ROW

对于update student set name='tom' where id=1操作，会记录id=1这条数据中name字段在修改前与修改后的数据。

优点：

准确性强

缺点：

可读性差，需要借助mysqlbinlog解析。

如果经常修改一些字段比较长的数据，会造成生成的binlog日志量变多，性能稍弱。

当然，alter table等直接改变表结构的语句，也会快速增加日志量与磁盘IO。

MIXED

其实就是一种对STATEMENT与ROW的混合使用方式

对不会造成歧义的操作使用STATEMENT格式进行记录，否则使用ROW格式记录。

对表结构的修改操作，也使用ROW格式进行记录。

不过，比较推荐的是ROW格式，特别是在SSD、云端存储、大带宽普及的今天，这点儿的存储空间与磁盘IO还是吃得消的，滴滴基于Binlog的采集架构就是直接使用的ROW格式。

binlog的使用场景

主从复制

当我们使用主从结构的mysql时，从库需要同步主库的数据。

这个时候主库会将自己的binlog异步发送给从库，从库在本地完成sql回放，来达到主从数据一致的目的。

主从复制之间可能会存在延迟，当主库只负责写，从库只负责读时，写完主库之后的立马读从库，可能会出现问题。

关于主从复制原理及主从延迟的解决方案，会另开篇幅。

数据恢复

当误删生产数据时，可以通过binlog来恢复。

找到生产库最近的一次全量备份，首先由全量备份恢复到临时库中。

接着从全量备份的时间点开始，重放binlog一直到mysql不产生新的binlog为止，另外要注意删除binlog中误操作的语句，最后切换临时库为生产库。

值得注意的一点是，binlog默认是不开启的。

---

redo log

又称重做日志，是Innodb引擎中特有的日志。如果当前使用的引擎是Myisam或者Memory，那就无从谈起redo log。

和binlog的内容不同，redo log记录了“在某个数据页上做了哪些修改”，属于物理日志。

为什么要有redo log?

Innodb引擎是以页为单位来和磁盘交互的，一般来说，如果一个事务提交后，需要将修改后的数据页写回到磁盘中。

如果本次事务只修改当前数据页中的几个Byte，直接将当前数据页的所有内容刷到磁盘后，涉及到大量的随机写，IO成本很高，性能比较低。

如果事务提交后，先将“对哪个数据页做了哪些修改”顺序写入redo log，之后会在合适的时机写回到buffer pool（你可以把buffer pool理解为缓冲池，如果查询到一条记录时，会将记录所在的数据页加载进缓冲池中。之后再进行查找时，先查询缓冲池，查不到再查磁盘，查到了就再放入到缓冲池中。这样做，在一定程度上可以减少IO成本，提升性能）中，最后将buffer pool中的数据页刷盘，在一定程度上可以减少IO成本。

此外，binlog是不支持crash-safe，即崩溃恢复的，只是支持误删数据恢复。当redo log与binlog结合在一起的时候，光芒就出现了，此处应该有迪迦。redo log中较实际数据页中多出来的那部分日志，就是崩溃后用于恢复的日志。

redo log的记录方式

和binlog追加写不同，redo log采用的是循环写。之所以用循环写，是因为之前恢复的数据再保存在redo log中就没有任何意义了。

假设redo log最终会写入到4个文件中，每个文件的大小都是1GB，则此时能够记录的最大日志量为4GB。

比如先从1号文件中写入，写满之后，就换到2号文件中。4个文件全部写满后，再回到1号文件从头继续写。

 

 这里还有两个指针，write position与check point

write position

指向redo log的记录进度，write position指针走过的区域，代表着redo log的日志量逐渐增长。

check point

指向数据页刷盘后的恢复进度，check point指针走过的区域，会将区域内redo log数据用于恢复，接着将redo log擦除。

 两个指针的运动方向，都是顺时针方向。

因此，从write position顺时针到check point之间的区域，都是空着的部分。

当redo log记录过快时，write position可能会追赶上check point。此时就需要停止redo log记录，并将所有文件中的redo log恢复。