上一篇学习了 SQL 的执行过程,这一篇主要的学习内容就在其基础上新增了一个重要的知识点,日志系统。
查询 SQL 语句执行回顾
mysql> select * from T where ID=10;
孔乙己喝酒的店铺老板
每个人喝酒吃肉不一定带够钱,所以有人会赊账,老板有一个记账本。但是老板每天很忙,来一个人就去翻一翻账,来一个人就去翻一翻账,很繁琐,而且记得多了,翻一次要翻好久,所以每个人的账务会先记在一块板子上,等不忙的时候再去记到记账本,然后把板子上的账务擦掉。
MySQL 的更新操作与其类似,有更新操作会先记录到一个叫做 redo log 的板子上,等没人的时候在记录到存储文件中。这就是 MySQL 日志系统中的一个重要角色 redo log
redo log 是一个可循环写的一个文件组。如一组 4 个文件 0 - 1 - 2 - 3 。
redo log 中有两个记录点
write pos 是当前记录的位置,一边写一边后移,写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件。
write pos 和 checkpoint 之间的是“粉板”上还空着的部分,可以用来记录新的操作。如果 write pos 追上 checkpoint,表示“粉板”满了,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint 推进一下。
有个 redo log 之后,InnoDB 引擎在数据库服务宕机的时候,仍然可以将数据恢复,前提是事务已经提交。这个能力成为 crash-safe
crash-safe : 赊账记录记在了粉板上或写在了账本上,之后即使掌柜忘记了,比如突然停业几天,恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。
MySQL 整体来看有两块:一块是 Server 层,它主要做的是 MySQL 功能层面的事情;还有一块是引擎层,负责存储相关的具体事宜。上面我们聊到的粉板 redo log 是 InnoDB 引擎特有的日志,而 Server 层也有自己的日志,称为 binlog(归档日志)。
最开始的时候存储引擎只有 MySQL 自己的 MyISAM,但是 MyISAM 没有 crash-safe 的功能。bin log 只能用于归档。InnoDB 是另外一家公司的存储引擎,为了解决 crash-safe 的问题,开发了 redo log 这个功能。
这两种日志有以下三点不同。
通过一条更新 SQL 来了解学习 MySQL 的日志系统。
mysql> create table T(ID int primary key, c int);
将 ID=2 这一行的值加 1
mysql> update T set c=c+1 where ID=2;
更新语句的执行过程
redo log 的两阶段提交,由它来保证 crash-safe 。
第一阶段 prepare,然后进行逻辑日志记录 binlog ,记录完成之逅,调用存储引擎的事务提交方法,此时 redo log 到第二阶段 commit;
redo log 为了解决即时性问题。 因为文件可循环写binlog 为了解决长时间历史性问题。
因为文件追加写使用两阶段提交保证了即时和历史数据的一致性。
通过 redo log 可以恢复近期数据,比如断点,异常重启等短期数据。
通过 binlog 可以恢复到某个时间点的数据。
上述具体时间可配。