MySQL为什么需要redolog和undolog?从数据页刷盘的四种策略考虑

Jaystrong 2020-05-14

1 针对未提交事务的刷盘策略

No Steal和Steal

  • No Steal:未提交的事务数据页不可以写入磁盘
  • Steal:未提交的事务数据页可以写入磁盘

2 针对提交事务的刷盘策略

No Force和Force

  • No Force:提交的事务数据页必须写入磁盘
  • Force:提交的事务数据页也可以不写入磁盘

3 排列组合

  • 第一种情况:No Steal和Force,即未提交事务不可以写入磁盘,提交事务必须写入磁盘
    如果系统宕机了,此时未提交的事务修改的数据页还停留在内存中,断电后重启,内存中的数据自然也就消失了,自动回滚;而对于已经提交的事务,根据Force的策略,其修改的数据页已经写入到磁盘进行持久化后,并没有收到影响,此时系统数据一致性可以得到保障。但是会出现什么问题呢?每次事务都要做一次磁盘IO,这样的性能是无法接受的。
  • 第二种情况:No Steal和No Force,即未提交事务不可以写入磁盘,提交事务可以暂不写入磁盘
    如果系统宕机了,未提交事务并不会收到影响,自动回滚掉,但是已提交的事务对应的脏页就没了,为了解决数据的一致性,MySQL引入了redolog机制,可以提供数据回放,解决内存数据丢失的问题。
  • 第三种情况:Steal和Force,即未提交事务可以写入磁盘,提交事务必须写入磁盘
    如果系统宕机了,已提交的事务,其修改的数据页已经写入到磁盘进行持久化后,并没有收到影响。但是未提交事务,已经修改的数据页持久化到了磁盘中,为了解决数据的一致性问题,引入undolog机制,提供数据快照,并往历史版本回滚。
  • 第四种情况:Steal和No Force,即未提交事务可以写入磁盘,提交事务可以暂不写入磁盘
    此时就必须引入redolog和undolog来一起解决上面说的内存数据丢失的问题。

相关推荐