有个星球水友提问:
沈老师,我们有一次 MySQL 崩溃,重启后发现有些已经提交的事务对数据的修改丢失了,不是说事务能保证 ACID 特性么,想问下什么情况下可能导致 “事务已经提交,数据却丢失” 呢?
这个问题有点复杂,且容我系统性梳理下思路,先从 redo log 说起吧。
_画外音:_水友问的是 MySQL,支持事务的是 InnoDB,本文以 InnoDB 为例展开叙述,其他数据库不是很了解,但估计原理是相同的。
为什么要有 redo log**?**
事务提交后,必须将事务对数据页的修改刷 (fsync) 到磁盘上,才能保证事务的 ACID 特性。
这个刷盘,是一个随机写,随机写性能较低,如果每次事务提交都刷盘,会极大影响数据库的性能。
随机写性能差,有什么优化方法呢?
架构设计中有两个常见的优化方法:
(1)先写日志 (write log first),将随机写优化为顺序写;
(2)将每次写优化为批量写;
这两个优化,数据库都用上了。
先说第一个优化,将对数据的修改先顺序写到日志里,这个日志就是 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 之后,就认为文件已经写完,如果不 flush,什么时候落盘,是操作系统决定的;
_画外音:_有时候打日志,明明 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 有三种策略:
(1)0:每秒 write 一次 OS cache,同时 fsync 刷磁盘,性能好;
(2)1:每次都 write 入 OS cache,同时 fsync 刷磁盘,一致性好;
(3)2:每次都 write 入 OS cache,每秒 fsync 刷磁盘,折衷;
四、高并发业务,行业内的最佳实践,是:
innodb_flush_log_at_trx_commit=2
知其然,知其所以然,希望大家有收获。
架构师之路 - 分享技术思路
相关文章:
《数据库索引,到底是什么做的?》
《MyISAM 与 InnoDB 的索引差异》
作业:
贵司线上的配置是多少?丢过数据么?