mysql 日志记录 archive_Mysql系列之 - 日志

Tip：假如生活欺骗了你，你能咋滴…

我是小刀，在互联网中夹缝求生。 我希望你开心…

Mysql ——日志

日志模块

redo log(重做日志)和binlog(归档日志)。

redo log

redo log 像一块“粉板”。更新的时候，先写到 redo log 和内存里，这次更新就算是结束了。等到合适的时机再写到磁盘里，大大减小了写磁盘的次数。

redo log 是固定大小、“循环写”的，就像粉板一样，顶多也就记个十几二十条，多了就记不下了，这时会把粉板上的帐都写到账本里，再擦掉粉板，从头开始记。假设 redo log 配置了4组文件，每个文件 1G ，一共可记录 4G 的操作，写满了就会擦掉一部分记录。

redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。

在做更新操作时，如果每一次更新操作都立即写进磁盘，那么整个过程IO成本、查找成本都很高。redo log就是为了解决这一问题，MySQL通过WAL(Write-Ahead Logging)技术，先把更新操作写入redo log日志，并更新内存，这时更新操作就完成了，同时InnoDB引擎会在适当的时候(系统比较空闲时)，将一批操作更新到磁盘里面。如果redo log写满时，就不能再执行新的更新，得停下来先擦掉redo log一些记录，写入磁盘，再执行新的更新。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe

redo log 和 binlog不同点：

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

2.redo log是物理日志，记录的是“在某个数据页上做了什么修改”；

3.binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1”。

4.binlog两种模式：statement格式记录SQL语句，row格式记录行的内容，两条(更新前和更新后)。

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

为什么有了 redo log 还需要 binlog?

其实 redo log 才是那个新来的仔。MySQL 自带了 binlog 日志用于归档，没有 crash-safe 的能力。InnoDB 引擎以插件的形式引入 MySQL 时，为了能够实现 crash-safe 的能力，引入了 redo log 。

一般我们用 binlog 做主从复制，数据恢复等操作。

update语句执行流程图

将redo log的写入拆成了两个步骤：prepare 和 commit，这就是“两阶段提交”。

“两阶段提交”的目的是为了让两份日志之间的逻辑一致。保证一致性。

数据恢复过程：

首先，找到最近的一次全量备份，从这个备份恢复到临时库；

然后，从备份的时间点开始，将备份的binlog依次取出来，重放到中午误删表之前的那个时刻。

最后把表数据从临时库取出来，按需要恢复到线上库去。

redo log 和 binlog 的两阶段提交

为什么需要两阶段提交？

我们先假设没有两阶段提交时，可能会有以下两种情况：

1. redo log 提交成功了，这时候数据库挂掉导致 binlog 没有成功写入。数据库重启之后通过 redo log 把数据恢复回来，但是 binlog 没有成功写入，导致我们在做主从复制或者数据恢复的时候，数据不一致。

2. binlog 提交成功了，这时候数据库挂掉导致 redo log 没有成功写入。数据库重启之后，无法恢复崩溃之前提交的那个事务，这部分数据更改在主库缺失。但是 binlog 已经成功写入了，从库反而有了该事务的改动，导致数据不一致。

综上我们知道，redo log 和 binlog 必须同时成功或同时失败，才能保证数据一致性。

那么 MySQL 是怎么知道 binlog 是否完整的？

一个事务的 binlog 是有完整的格式的：

statement 格式的 binlog，最后会有 COMMIT;

row 格式的 binlog，最后会有一个 XID event。