MYSQL独孤九剑日志系统之binlogredolog

Posted 2021-04-30 在下uptown

    周六早起一会感觉时间多了好多......下午约好跟小青年每周一鸡，晚上跟腿哥吃着火锅唱着歌，前几星期感觉周末过得贼快，时间管理不到位，不能跟着腿哥学，当年在实验室看他桌面的近期计划"Js逆向解析"，前几天问他还是Js逆向解析，可能这就是所谓的十年磨一剑吧，上周水了一篇，这周来点硬的，刚看完小米十周年演讲录播赶紧来更，不得不说雷总越来越帅了，还是那么客气，开场谢前谢后的，跟两年前一样。。。

上次mysql文章中简单说了一条查询语句是怎么执行的，从连接器->分析器->优化器->执行器最后到达存储引擎。

    想必大家肯定听过很多江湖传闻MySQL可以恢复到半个月内任意一秒的状态，你难道不想知道其中的原理吗。想当年delete语句少加了一个where条件，那时候也不知道用日志恢复，连夜重新添回来，当时都想买票跑路了算了，提一嘴，mysql默认是不开启日志的。

mysql> create table T(ID int primary key, c int);mysql> update T set c=c+1 where ID=2;

    还是从一条sql开始，首先创建一个表T，然后执行update语句，具体的执行流程就是分析器解析出是更新语句，优化器选择走id索引，执行器去找到这一条数据执行更新。看起来似乎跟查询语句一样要走一遍那几个组件，但是更新语句的流程会涉及到两个日志文件，那就是今天的主角，redolog与binlog。

redolog

    这里借助下极客时间举得一个很形象的例子:

不知道你还记不记得《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记录。如果赊账的人不多，那么他可以把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。

如果有人要赊账或者还账的话，掌柜一般有两种做法：

• 一种做法是直接把账本翻出来，把这次赊的账加上去或者扣除掉；

• 另一种做法是先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。

在生意红火柜台很忙时，掌柜一定会选择后者，因为前者操作实在是太麻烦了。首先，你得找到这个人的赊账总额那条记录。你想想，密密麻麻几十页，掌柜要找到那个名字，可能还得带上老花镜慢慢找，找到之后再拿出算盘计算，最后再将结果写回到账本上。这整个过程想想都麻烦。相比之下，还是先在粉板上记一下方便。你想想，如果掌柜没有粉板的帮助，每次记账都得翻账本，效率是不是低得让人难以忍受？

    鲁迅都懂的设计思路你再不懂

    同理，mysql也做了相应的处理，如果每一次更新操作都要写入磁盘，磁盘找到对应的一条数据更新，整个io成本会很高。而粉板和账本配合的整个过程，其实就是MySQL里经常说到的WAL技术，WAL的全称是Write-Ahead Logging（面试官整就喜欢整洋词），先写日志，再写磁盘。

    那么这个粉板就相当于redolog，而账本就是我们的磁盘了，也就是说当我们更新一条数据时，innodb引擎(redolog是innodb引擎特有)会先写到redolog里，并更新到内存中，这时就会返回更新结果，其实真实落盘的数据还没来得及改，它会像掌柜的似的空闲的时候再更新到磁盘中，更新到磁盘的操作就叫flush操作。

   

    粉板总有写完的时候，redolog也有固定的大小，比如可以配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就可以记录4GB的操作，用完了再从头开始循环写。

write pos是当前记录的位置,一边写一边后移，写到第3号末尾从第0号重头开始

checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。如果write pos追上checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint往前推进一下。有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。只要赊账记录记在了粉板上，就算突然停业几天，恢复后依然可以通过账本结合粉板上的数据明确欠的钱。

binlog

    最早知道这个日志还是在搭建数据库主从配置的时候，主库复制增删改同步到从库，从库负责查，降低数据库压力，主从之间的数据同步就是通过binlog日志实现的，主库执行完语句记录到日志中，从库定时拉取日志实现同步。(不过当时就那点用户量做个主从颇有点掩耳盗铃的意思)，那么binlog到底记录着什么，你可以通过/etc/my.cnf下配置binlog目录

[mysqld]# binlog 配置log-bin = /usr/local/var/mysql/logs/mysql-bin.logexpire-logs-days = 14max-binlog-size = 500Mserver-id = 1

其实binlog里就是记录了大量sql语句，所以如果不小心误删了数据可以通过日志恢复。

既生瑜何生亮

    最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有crash-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。俩日志总结一下：

1、redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

2、redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1

(是不是没还是没懂有啥区别？binlog里存的是sql语句，而redolog直接记的session_id + date + file_id + block_id + 修改数据，也就是修改后的数据)

3、redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

两阶段提交

   再来理一下那条update语句执行流程。

1、执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

2、执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

3、引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后告知执行器执行完成了，随时可以提交事务。

4、执行器生成这个操作的binlog，并把binlog写入磁盘。

5、执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更新完成。

这里有一点注意一首，redolog采用了两阶段提交机制，一段prepare一段commit。由于redolog和binlog是两个独立的逻辑，如果不用两阶段提交，要么就是先写完redolog再写binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。仍然用前面的update语句来做例子。

update T set c=c+1 where ID=2;

假设当前ID=2的行，字段c的值是0，执行update语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了事故。

先写redolog后写binlog。假设在redolog写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redolog写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。

先写binlog后写redolog。如果在binlog写完之后发送事故，由于redolog还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。

可以看到，如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

    简单说，redolog和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

   哇真的累，从上午写到现在，整理文章真是个督促人学习的好办法。好了，Time to chicken dinner，伞兵一号Uptown准备就绪。

乘风破浪Uptown