Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-27610

Unnecessary wait in InnoDB crash recovery

Details

    Description

      As noted in MDEV-14481, there is an unnecessary wait and some dead code in the function recv_sys_t::apply(). Before the function buf_page_get_low() can return, it must acquire an exclusive page latch, and the page must have been read. If the page is being read by another thread, that other thread would already have read-fixed and X-latched the page. Furthermore, before buf_page_read_complete() would return, it would have invoked recv_recover_page() to apply any redo log to the page, before releasing the page latch.

      It actually suffices to simply call recv_read_in_area() in order to trigger a transition from page_recv_t::RECV_NOT_PROCESSED to page_recv_t::RECV_BEING_READ for the current block and possibly some following page numbers.

      This dead code seems to be present in all InnoDB versions. I think that this is only feasible to fix in 10.5 or later versions, thanks to code simplification that was performed in MDEV-19586, MDEV-21351 and many other tickets.

      Attachments

        Issue Links

          Activity

            The code (bb-10.5-MDEV-27610, a79a1744) looks good to me.

            It's supposed that recv_recover_page() will be invoked from fil_aio_callback(), and there is no need to invoke it from recv_sys_t::apply() synchronously with the page latching.

            pages.erase(r) is removed from recv_sys_t::apply(), but pages.clear() is invoked at the end of recv_sys_t::apply().

            I don't see errors in the code.

            vlad.lesin Vladislav Lesin added a comment - The code (bb-10.5- MDEV-27610 , a79a1744) looks good to me. It's supposed that recv_recover_page() will be invoked from fil_aio_callback(), and there is no need to invoke it from recv_sys_t::apply() synchronously with the page latching. pages.erase(r) is removed from recv_sys_t::apply(), but pages.clear() is invoked at the end of recv_sys_t::apply(). I don't see errors in the code.

            The tree origin/bb-10.5-MDEV-27610 a79a1744595fa80848338809c7cc67086e8ed5fd 2022-01-25T11:09:49+02:00
            behaved well in RQG based testing of Crash Recovery.
            None of the tests running DML only failed in the sequence   kill DB server, restart with recovery, check the tables with various methods.
            Tests running DDL showed various known bad effects. But this was to be expected because DDL is not crash safe in MariaDB 10.5 and lower.
            

            mleich Matthias Leich added a comment - The tree origin/bb-10.5-MDEV-27610 a79a1744595fa80848338809c7cc67086e8ed5fd 2022-01-25T11:09:49+02:00 behaved well in RQG based testing of Crash Recovery. None of the tests running DML only failed in the sequence kill DB server, restart with recovery, check the tables with various methods. Tests running DDL showed various known bad effects. But this was to be expected because DDL is not crash safe in MariaDB 10.5 and lower.

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.