有个水友提问:
沈老师,我们有一次MySQL崩溃,检查重启后发现有些已经提交的配置事务对数据的修改丢失了,不是事数据说事务能保证ACID特性么,想问下什么情况下可能导致“事务已经提交,提交数据却丢失”呢?
这个问题有点复杂,却丢得先从redo log说起。
事务提交后,必须将事务对数据页的修改刷(fsync)到磁盘上,才能保证事务的ACID特性。
这个刷盘,是一个随机写,随机写性能较低,如果每次事务提交都刷盘,会极大影响数据库的性能。
架构设计中有两个常见的优化方法:
这两个优化,数据库都用上了。
先说第一个优化,将对数据的修改先顺序写到日志里,这个日志就是redo log。
假如某一时刻,数据库崩溃,还没来得及将数据页刷盘,数据库重启时,会重做redo log里的内容,以保证已提交事务对数据的影响被刷到磁盘上。
一句话,redo log是为了保证已提交事务的ACID特性,同时能够提高数据库性能的技术。
既然redo log能保证事务的ACID特性,那为什么还会出现,水友提问中出现的“数据库崩溃,丢数据”的问题呢?一起看下redo log的实现细节。
画了一个丑图,简单说明下redo log的三层架构:
首先,事务提交的时候,会写入Log Buffer,这里调用的是MySQL自己的函数WriteRedoLog;
接着,只有当MySQL发起系统调用写文件write时,Log Buffer里的数据,才会写到OS cache。注意,MySQL系统调用完write之后,就认为文件已经写完,如果不flush,什么时候落盘,是操作系统决定的;
画外音:有时候打日志,明明printf了,tail -f却看不到,就是这个原因,操作系统还没有刷盘。
最后,由操作系统(当然,MySQL也可以主动flush)将OS cache里的数据,最终fsync到磁盘上。
这里就是将“每次写”优化为“批量写”,以提高操作系统性能。
这也是“每次写”优化为“批量写”思路的体现,以提高数据库性能。
画外音:这个优化思路,非常常见,高并发的MQ落盘,高并发的业务数据落盘,都可以使用。 redo log的三层架构,MySQL做了一次批量写优化,OS做了一次批量写优化,确实能极大提升性能,但有什么副作用吗?
画外音:有优点,必有缺点。
这个副作用,就是可能丢失数据:
画外音:如上文所说,应用程序系统调用完write之后(不可能每次write后都立刻flush,这样写日志很蠢),就认为写成功了,操作系统何时fsync,应用程序并不知道,如果操作系统崩溃,数据可能丢失。
任何脱离业务的技术方案都是耍流氓:
MySQL有一个参数:
innodb_flush_log_at_trx_commit
能够控制事务提交时,刷redo log的策略。
目前有三种策略:
策略一:最佳性能(innodb_flush_log_at_trx_commit=0)
策略二:强一致(innodb_flush_log_at_trx_commit=1)
策略三:折衷(innodb_flush_log_at_trx_commit=2)
画外音:磁盘IO次数不确定,因为操作系统的fsync频率并不是MySQL能控制的。
画外音:因为OS也会fsync,MySQL主动fsync的周期是一秒,所以最多丢一秒数据。
讲了这么多,回到水友的提问上来,数据库崩溃,重启后丢失了数据,有很大的可能,是将innodb_flush_log_at_trx_commit参数设置为0了,这位水友最好和DBA一起检查一下InnoDB的配置。
高并发业务,行业最佳实践,是使用第三种折衷配置(=2),这是因为:
(1) 为了保证事务的ACID特性,理论上每次事务提交都应该刷盘,但此时效率很低,有两种优化方向:
(2) redo log是一种顺序写,它有三层架构:
(3) 为了满足不同业务对于吞吐量与一致性的需求,MySQL事务提交时刷redo log有三种策略:
(4) 高并发业务,行业内的最佳实践,是:
innodb_flush_log_at_trx_commit=2
知其然,知其所以然,希望大家有收获。
责任编辑:赵宁宁 来源: 架构师之路 MySQL事务数据库(责任编辑:知识)
神火股份:3月23日融资净偿还37.10万元 当前融资余额为6.29亿元
杭州亚运会配套工程钱塘过江隧道建成通车 设计为双洞双向六车道
一季度浙江省宁波重点工程项目完成投资427.60亿元 实现开门红
实现“双过半”!四川泸石高速建设持续加速 将于2024年底全线建成通车
雄安新区首台盾构“雄安一号”始发 开启雄安新区地下工程建设的新篇章
四川省自贡市做强工业主引擎 上半年完成工业投资111.4亿元