我看了文献资料相当彻底,但仍然无法弄清楚,所以问这个问题。
在InnoDB中,我了解到对缓冲池的任何更新都是由重做日志跟踪的,该日志在磁盘上被持久化,在崩溃的情况下,重做日志用于恢复。
偶尔,MySQL服务器也会刷新缓冲区池的脏页。在正常运行的情况下,MySQL服务器只刷新部分脏页,称之为“模糊检查点”。根据此过程,通过读取磁盘上页的内容,然后应用LSN大于上一个检查点的所有重做日志,可以恢复当前缓冲区池。
我的问题是,MySQL服务器如何选择要刷新哪些脏页,以及如何支持崩溃可恢复性?
通过一些googling,我了解到,通过使用脏页的第一个修改LNS号,人们可以知道哪些页面应该被刷新,这样检查点LNS就可以增加。
但是,带有最早的未校验点重做日志的脏页也可以被最新的事务修改,因此与最早的未校验点重做日志相比,它具有未来的内容。如果磁盘持久化缓冲池页包含这样的未来内容,那么我假设很难(如果可能的话)重做。
发布于 2019-09-17 15:55:39
(我非常肯定以下几点。)
InnoDB不依赖于“脏”页面进行恢复。恢复是通过iblog*和双写缓冲区中存储的内容来保证的。
假定有关事务的信息可以更紧凑地存储在重做日志(相对于实际表)中,并且可以更快地写入磁盘。
日志文件被覆盖,但直到LNS说它是可以的。因此,刷新的最佳脏页要么是“最近使用最少的”页面,要么是日志中位置最老的页面。我不知道它用什么算法来决定这些冲突的事情。
如果有大量的活动导致buffer_pool的百分比“太接近”到100%的脏,那么InnoDB就会改变方向,更积极地冲洗脏页。这也是一种权衡。
还请注意,对非唯一二级索引的更改的写入也是“延迟”的。这是在"change“中,它(默认情况下)占buffer_pool的25%。这样做的希望是,更新可以以较少的读-修改-写周期被排序和写入磁盘。同样,恢复不依赖于这已经完全刷新到磁盘,而重做日志是关键的部分。
双写缓冲区可以防止“撕掉的页”。这是一种潜在的灾难性情况,磁盘子系统写不能在原子操作中写入所有16‘t。一些较新的磁盘保证原子性,因此可以关闭设置。
InnoDB是防撞的.但是,由于延迟I/O,以及这些在高负载下高效工作的各种技术,它也是“快速”的。
https://dba.stackexchange.com/questions/248937
复制相似问题