mysql-redo log写流程分析(转)

原文链接：https://mp.weixin.qq.com/s/-Hx2KKYMEQCcTC-ADEuwVA

为什么我的事务提交了，还会丢失数据呢？

这要从innoDB的一个参数说起

innodb_flush_log_at_trx_commit

参数的字面意思是innodb在事务提交时更新日志的方式，这个参数有 0，1，2 三种取值，表示有三种方式更新日志

首先我们要弄清楚事务提交时会更新那些日志呢？

前滚日志redo log 和 回滚日志undo log ，这两者称为innodb的事务日志。

事务提交后，存储引擎要将事务对数据的修改刷写到磁盘上以保证事务的ACID特性

A: atomicity-原子性

C: consistency-一致性

I: isolation-隔离性

D: durability-持久性

这个刷盘，是一个随机写，随机写性能较低，如果每次事务提交都刷盘，会极大影响数据库的性能。

知其然，知其所以然。思路比结论重要

所以为了优化随机写带来的低性能，架构设计中有两个常见的优化方法：

（1）先写日志(write log first)，将随机写优化为顺序写；

（2）将每次写优化为批量写；

这两个优化，InnoDB都用上了。

先说第一个优化，将对数据的修改先顺序写到日志里，这个日志就是redo log。

假如某一时刻，数据库崩溃，还没来得及将数据页刷盘，数据库重启时，会重做redo log里的内容，以保证已提交事务对数据的影响被刷到磁盘上。因此，redo log 又称为重做日志。

一句话定义，redo log是为了保证已提交事务的ACID特性，同时能够提高数据库性能的技术。

既然redo log能保证事务的ACID特性，那为什么还会出现，水友提问中出现的“数据库奔溃，丢数据”的问题呢？一起看下redo log的实现细节。

redo log的三层架构

画了一个丑图，简单说明下redo log的三层架构：

• 粉色，是InnoDB的一项很重要的内存结构(In-Memory Structure)，日志缓冲区(Log Buffer)，这一层，是MySQL应用程序用户态
• 屎黄色，是操作系统的缓冲区(OS cache)，这一层，是OS内核态
• 蓝色，是落盘的日志文件

redo log最终落盘的步骤如何？

首先，事务提交的时候，会写入Log Buffer，这里调用的是MySQL自己的函数WriteRedoLog；

接着，只有当MySQL发起系统调用写write时，Log Buffer里的数据，才会写到OS cache。注意，MySQL系统调用完write之后，就认为文件已经写完，至于什么时候落盘，是操作系统决定的；

画外音：有时候打日志，明明printf了，tail -f**却看不到，就是这个原因，这个细节在《明明打印到文件了，为啥tail -f看不到》一文里说过，此处不再展开。

最后，由操作系统（当然，MySQL也可以主动flush）将OS cache里的数据，最终fsync到磁盘上；

操作系统为什么要缓冲数据到OS cache里，而不直接刷盘呢？

这里就是将“每次写”优化为“批量写”，以提高操作系统性能。

数据库为什么要缓冲数据到Log Buffer里，而不是直接write呢？

这也是“每次写”优化为“批量写”思路的体现，以提高数据库性能。

画外音：这个优化思路，非常常见，高并发的MQ落盘，高并发的业务数据落盘，都可以使用。

redo log的三层架构，MySQL做了一次批量写优化，OS做了一次批量写优化，确实能极大提升性能，但有什么副作用吗？

画外音：有优点，必有缺点。

这个副作用，就是可能丢失数据：

（1）事务提交时，将redo log写入Log Buffer，就会认为事务提交成功；

（2）如果写入Log Buffer的数据，write入OS cache之前，数据库崩溃，就会出现数据丢失；

（3）如果写入OS cache的数据，fsync入磁盘之前，操作系统奔溃，也可能出现数据丢失；

画外音：如上文所说，应用程序系统调用完write之后（不可能每次write后都立刻flush，这样写日志很蠢），就认为写成功了，操作系统何时fsync，应用程序并不知道，如果操作系统崩溃，数据可能丢失。

任何脱离业务的技术方案都是耍流氓：

（1）有些业务允许低效，但不允许一丁点数据丢失；

（2）有些业务必须高性能高吞吐，能够容忍少量数据丢失；

MySQL是如何折衷的呢？

MySQL有一个参数：

innodb_flush_log_at_trx_commit

能够控制事务提交时，刷redo log的策略。

目前有三种策略：

策略一：最佳性能(innodb_flush_log_at_trx_commit=0)

每隔一秒，才将Log Buffer中的数据批量write入OS cache，同时MySQL主动fsync。

这种策略，如果数据库奔溃，有一秒的数据丢失。

策略二：强一致(innodb_flush_log_at_trx_commit=1)

每次事务提交，都将Log Buffer中的数据write入OS cache，同时MySQL主动fsync。

这种策略，是InnoDB的默认配置，为的是保证事务ACID特性。

策略三：折衷(innodb_flush_log_at_trx_commit=2)

每次事务提交，都将Log Buffer中的数据write入OS cache；

每隔一秒，MySQL主动将OS cache中的数据批量fsync。

画外音：磁盘IO次数不确定，因为操作系统的fsync频率并不是MySQL能控制的。

这种策略，如果操作系统奔溃，最多有一秒的数据丢失。

画外音：因为OS也会fsync，MySQL主动fsync的周期是一秒，所以最多丢一秒数据。

讲了这么多，回到水友的提问上来，数据库崩溃，重启后丢失了数据，有很大的可能，是将innodb_flush_log_at_trx_commit参数设置为0了，这位水友最好和DBA一起检查一下InnoDB的配置。

可能有水友要问，高并发的业务，InnoDB运用哪种刷盘策略最合适？

高并发业务，行业最佳实践，是使用第三种折衷配置（=2），这是因为：

1. 配置为2和配置为0，性能差异并不大，因为将数据从Log Buffer拷贝到OS cache，虽然跨越用户态与内核态，但毕竟只是内存的数据拷贝，速度很快；
2. 配置为2和配置为0，安全性差异巨大，操作系统崩溃的概率相比MySQL应用程序崩溃的概率，小很多，设置为2，只要操作系统不奔溃，也绝对不会丢数据。

总结

一、为了保证事务的ACID特性，理论上每次事务提交都应该刷盘，但此时效率很低，有两种优化方向：

1. 随机写优化为顺序写；
2. 每次写优化为批量写；

二、redo log是一种顺序写，它有三层架构：

1. MySQL应用层：Log Buffer
2. OS内核层：OS cache
3. OS文件：log file

三、为了满足不用业务对于吞吐量与一致性的需求，MySQL事务提交时刷redo log有三种策略：

• 0：每秒write一次OS cache，同时fsync刷磁盘，性能好；
• 1：每次都write入OS cache，同时fsync刷磁盘，一致性好；
• 2：每次都write入OS cache，每秒fsync刷磁盘，折衷；

四、高并发业务，行业内的最佳实践，是：

innodb_flush_log_at_trx_commit=2