《MySQL实战45讲》学习笔记2——MySQL的日志系统

1、日志类型

• 逻辑日志：存储了逻辑SQL修改语句
• 物理日志：存储了数据被修改的值

2、binlog

1.定义

binlog 是 MySQL 的 逻辑日志，也叫二进制日志、归档日志，由 MySQL Server 来记录。

用于记录用户对数据库操做的SQL语句（除了查询语句）信息，以二进制的形式保存在磁盘中。

 

2.记录方式

binlog 经过 追加的方式写入的，可经过配置参数 max_binlog_size 设置每一个 binlog 文件的大小，当文件大小大于给定值后，日志会发生滚动，以后的日志记录到新的文件上。

 

3.格式 

binlog 日志有三种格式，分别为 STATMENT、ROW 和 MIXED。

 

	STATMENT	ROW
说明	基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。 是bin log的默认格式。	基于行的复制(row-based replication, RBR)：不记录每一条SQL语句的上下文信息，仅保存哪条记录被修改。
优势	不须要记录每一条SQL语句与每行的数据变化，减小了bin log的日志量，节约了磁盘IO，提升性能。	会很是清楚的记录下每一行数据修改的细节，不会出现某些特定状况下的存储过程、或function、或trigger的调用和触发没法被正确复制的问题。
缺点	在某些状况下会致使master-slave中的数据不一致，如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题。	会产生大量的日志，尤为是alter table的时候会让日志暴涨。

MIXED模式是基于 STATMENT 和 ROW 两种模式的混合复制(mixed-based replication, MBR)，通常的复制使用STATEMENT模式保存 binlog，对于 STATEMENT 模式没法复制的操做使用ROW模式保存 binlog，MySQL 会根据执行的 SQL 语句选择日志保存方式。

 

3、redo log

1.定义：

redo log 是 MySQL 的 物理日志，也叫重作日志，记录存储引擎 InnoDB 的事务日志。

 

MySQL 每执行一条 SQL 更新语句，不是每次数据更改都马上写到磁盘，而是先将记录写到 redo log 里面，并更新内存（这时内存与磁盘的数据不一致，将这种有差别的数据称为 脏页），一段时间后，再一次性将多个操做记录写到到磁盘上，这样能够减小磁盘 io 成本，提升操做速度。 先写日志，再写磁盘，这就是 MySQL 里常常说到的 WAL 技术，即 Write-Ahead Logging，又叫预写日志。MySQL 经过 WAL 技术保证事务的持久性。

 

2.记录方式

InnoDB 的 redo log 大小是固定的，采用 循环写的方式记录，当写到结尾时，会回到开头循环写日志。以下图：

write pos表示日志当前记录的位置，当ib_logfile_4写满后，会从ib_logfile_1从头开始记录；

check point表示将日志记录的修改写进磁盘，完成数据落盘，数据落盘后check point会将日志上的相关记录擦除掉，

即write pos->check point之间的部分是redo log空着的部分，用于记录新的记录，check point->write pos之间是redo log待落盘的数据修改记录。当write pos追上check point时，得先停下记录，先推进check point向前移动，空出位置记录新的日志。

 

有了 redo log，当数据库发生宕机重启后，可经过 redo log 将未落盘的数据（check point以后的数据）恢复，保证已经提交的事务记录不会丢失，这种能力称为 crash-safe。

 

4、两阶段提交

有了 redo log，为何还须要 binlog 呢？先来看看 binlog 和redo log 的区别：

	redo log	binlog
文件大小	redo log 的大小是固定的。	binlog 可经过配置参数max_binlog_size 设置每一个 binlog 文件的大小。
实现方式	redo log 是 InnoDB 引擎层实现的，并非全部引擎都有。	binlog是 Server 层实现的，全部引擎均可以使用 binlog 日志。
记录方式	redo log 采用循环写的方式记录，当写到结尾时，会回到开头循环写日志。日志上的记录修改落盘后，日志会被覆盖掉，没法用于数据回滚/数据恢复等操做。	binlog 经过追加的方式记录，当文件大小大于给定值后，日志会发生滚动，以后的日志记录到新的文件上，不会覆盖之前的记录。

由 binlog 和 redo log 的区别可知：binlog 日志只用于归档，只依靠 binlog 是没有 crash-safe 能力的。但只有 redo log 也不行，由于 redo log 是InnoDB 特有的，且日志上的记录落盘后会被覆盖掉。所以须要 binlog 和 redo log 两者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。

 

当执行一条 SQL 更新语句时，过程以下：

能够看到，在“两阶段提交”阶段，将 redo log 的写入分红了两步：prepare 和 commit。在 redo log 状态为 prepare 时记录 binlog 能够保证两个日志的记录一致。

 

5、若是数据库误操做, 如何执行数据恢复?

DB宕机后重启，InnoDB 会首先去查看数据页中的LSN的数值。这个值表明数据页被刷新回磁盘的 LSN 的大小。而后再去查看 redo log 的 LSN 的大小。

若是数据页中的 LSN 值大说明数据页领先于 redo log 刷新回磁盘，不须要进行恢复。反之须要从redo log中恢复数据。

 

注：LSN 是 日志序列号， 为 log sequence number 的缩写，主要用于发生 crash 时对数据进行 recovery。LSN是一个一直递增的整型数字，表示事务写入到日志的字节总量。

LSN 不只只存在于重作日志中，在每一个数据页头部也会有对应的 LSN 号，该 LSN 记录当前页最后一次修改的 LSN 号，用于在 recovery 时对比重作日志 LSN 号决定是否对该页进行恢复数据。

前面说的check point也是由 LSN 号记录的，LSN 号串联起一个事务开始到恢复的过程。

 

若是将 innodb_flush_log_at_trx_commit 和 sync_binlog 参数设置成 1，前者表示每次事务的 redo log 都直接持久化到磁盘，后者表示每次事务的 binlog 都直接持久化到磁盘，能够双重保证 MySQL 异常重启以后的数据不会丢失。