V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zxCoder
V2EX  ›  数据库

请教一个 MySQL 数据库 redo 日志恢复的问题

  •  
  •   zxCoder · 2021-03-10 21:53:39 +08:00 · 952 次点击
    这是一个创建于 1346 天前的主题,其中的信息可能已经有所发展或是发生改变。

    看一本书,上面这样介绍。

    - 跳过已经刷新到磁盘的页面
    
    我们前边说过,checkpoint_lsn 之前的 redo 日志对应的脏页确定都已经刷到磁盘了,但是
    checkpoint_lsn 之后的 redo 日志我们不能确定是否已经刷到磁盘,主要是因为在最近做的一次
    checkpoint 后,可能后台线程又不断的从 LRU 链表 和 flush 链表 中将一些脏页刷出 Buffer Pool 。这些在 checkpoint_lsn 之后的 redo 日志,如果它们对应的脏页在奔溃发生时已经刷新到磁盘,那在恢复时也就没有必要根据 redo 日志的内容修改该页面了。
    那在恢复时怎么知道某个 redo 日志对应的脏页是否在奔溃发生时已经刷新到磁盘了呢?这还得从页面的结构说起,我们前边说过每个页面都有一个称之为 File Header 的部分,在 File Header 里有一个称之为 FIL_PAGE_LSN 的属性,该属性记载了最近一次修改页面时对应的 lsn 值(其实就是页面控制块中的 newest_modification 值)。如果在做了某次 checkpoint 之后有脏页被刷新到磁盘中,那么该页对应的 FIL_PAGE_LSN 代表的 lsn 值肯定大于 checkpoint_lsn 的值,凡是符合这种情况的页面就不需要重复执行 lsn 值小于 FIL_PAGE_LSN 的 redo 日志了,所以更进一步提升了奔溃恢复的速度
    

    我的问题是这个FIL_PAGE_LSN属性只是记录了这个页面最近一次修改的 lsn 值,但是修改了也不一定会马上刷回磁盘啊,为什么通过这个就可以确定“不需要重复执行 lsn 值小于 FIL_PAGE_LSN 的 redo 日志了”

    3 条回复    2021-03-11 08:26:00 +08:00
    wps353
        1
    wps353  
       2021-03-10 22:05:16 +08:00 via Android
    其实你看的书已经写明了前置条件“如果在做了某次 checkpoint 之后有脏页被刷新到磁盘中,那么该页对应的 FIL_PAGE_LSN 代表的 lsn 值肯定大于 checkpoint_lsn 的值”
    littlewing
        2
    littlewing  
       2021-03-11 02:27:09 +08:00 via iPhone
    FIL_PAGE_LSN 就是从数据页的头里取的,肯定已经刷盘了啊
    zxCoder
        3
    zxCoder  
    OP
       2021-03-11 08:26:00 +08:00
    @littlewing 是我想错了。。。想成 buffer pool 里的页了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2604 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 10:39 · PVG 18:39 · LAX 02:39 · JFK 05:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.