mysql事务、redo日志、undo日志、checkpoint详解

转载: https://zhuanlan.zhihu.com/p/34650908

事务:

 说起mysql innodb存储引擎的事务,首先想到就是ACID(不知道的请google),数据库是如何做到ACID的呢?举个例子:

 数据库数据存放的文件称为data file;日志文件称为log file;数据库数据是有缓存的,如果没有缓存,每次都写或者读物理disk,那性能就太低下了。数据库数据的缓存称为data buffer,日志(redo)缓存称为log buffer;既然数据库数据有缓存,就很难保证缓存数据(脏数据)与磁盘数据的一致性。比如某次数据库操作:

update driver_info set driver_status = 2 where driver_id = 10001;

 更新driver_status字段的数据会存放在缓存中,等待存储引擎将driver_status刷新data_file,并返回给业务方更新成功。如果此时数据库宕机,缓存中的数据就丢失了,业务方却以为更新成功了,数据不一致,也没有持久化存储。

上面的问题就可以通过事务的ACID特性来保证。

BEGIN trans;

update driver_info set driver_status = 2 where driver_id = 10001;

COMMIT;

 这样执行后,更新要么成功,要么失败。业务方的返回和数据库data file中的数据保持一致。要保证这样的特性这就不得不说存储引擎innodb的redo和undo日志。

redo日志、undo日志:

 存储引擎也会为redo undo日志开辟内存缓存空间,log buffer。磁盘上的日志文件称为log file,是顺序追加的,性能非常高,注:磁盘的顺序写性能比内存的写性能差不了多少。

 undo日志用于记录事务开始前的状态,用于事务失败时的回滚操作;redo日志记录事务执行后的状态,用来恢复未写入data file的已成功事务更新的数据。例如某一事务的事务序号为T1,其对数据X进行修改,设X的原值是5,修改后的值为15,那么Undo日志为<T1, X, 5>,Redo日志为<T1, X, 15>。

梳理下事务执行的各个阶段:

 (1)写undo日志到log buffer;

 (2)执行事务,并写redo日志到log buffer;

 (3)如果innodb_flush_log_at_trx_commit=1,则将redo日志写到log file,并刷新落盘。

 (4)提交事务。

可能有同学会问,为什么没有写data file,事务就提交了?

在数据库的世界里,数据从来都不重要,日志才是最重要的,有了日志就有了一切。

 因为data buffer中的数据会在合适的时间 由存储引擎写入到data file,如果在写入之前,数据库宕机了,根据落盘的redo日志,完全可以将事务更改的数据恢复。好了,看出日志的重要性了吧。先持久化日志的策略叫做Write Ahead Log,即预写日志。

分析几种异常情况:

  • innodb_flush_log_at_trx_commit=2(innodb_flush_log_at_trx_commit和sync_binlog参数详解)时,将redo日志写入logfile后,为提升事务执行的性能,存储引擎并没有调用文件系统的sync操作,将日志落盘。如果此时宕机了,那么未落盘redo日志事务的数据是无法保证一致性的。
  • undo日志同样存在未落盘的情况,可能出现无法回滚的情况。

checkpoint:

  checkpoint是为了定期将db buffer的内容刷新到data file。当遇到内存不足、db buffer已满等情况时,需要将db buffer中的内容/部分内容(特别是脏数据)转储到data file中。在转储时,会记录checkpoint发生的”时刻“。在故障回复时候,只需要redo/undo最近的一次checkpoint之后的操作。

上一篇:HDU_2051——十进制到二进制转换


下一篇:前端学习之——js解析json数组