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

MariaDB 10.1 fails to start datadir created with MariaDB 10.0/MySQL 5.6 using innodb-page-size!=16K

Details

    • 10.2.4-5, 10.1.21

    Description

      Error log will contain:

      InnoDB: Error: Current page size 8192 !=  page size on page 16384
      Error: JAN: pageno 8191 offset 3772
      2016-12-21 14:08:08 140182760941440 [ERROR] InnoDB: innodb-page-size mismatch in data file ./ibdata1
      

      Attachments

        Issue Links

          Activity

            jplindst Jan Lindström (Inactive) added a comment - http://lists.askmonty.org/pipermail/commits/2016-December/010324.html

            I think that more testing and a detailed plan of how to upgrade from 10.1 to 10.2 is needed.

            marko Marko Mäkelä added a comment - I think that more testing and a detailed plan of how to upgrade from 10.1 to 10.2 is needed.
            jplindst Jan Lindström (Inactive) added a comment - bb-10.1-jplindst or http://lists.askmonty.org/pipermail/commits/2016-December/010356.html

            10.2 will use same flags as fixed 10.1.

            jplindst Jan Lindström (Inactive) added a comment - 10.2 will use same flags as fixed 10.1.

            The latest patch looks good to me, patch looks great to me, except for one thing: I think that we should write the corrected flags back to the data file.

            Given that 10.1 is already in GA status, we should consider our options carefully. My preference would be (1) below:

            (1) If we adjust 10.1.21 so that it writes back corrected flags for both old and new data files, then older 10.1.x would be unable to open the files (if compression, DATA_DIRECTORY or non-default innodb_page_size was used).

            (2) If we adjust 10.1.21 so that it writes correct flags for new data files (like the current patch does), then older 10.1.x would not be able to read those created-with-newer-version data files.

            (3) If we adjust 10.2 only, so that it writes the correct flags for new files and also adjusts the flags in old files, then we would seem to have a clear upgrade path.

            Whatever we choose, I would like to remove the flag-adjustment code from 10.3 or 10.4. This would mean that an upgrade (or import) directly from 10.1 is only possible if the problematic features (DATA_DIRECTORY, compression, non-standard innodb_page_size) were not used. Otherwise the upgrade would have to be done through 10.2.

            marko Marko Mäkelä added a comment - The latest patch looks good to me, patch looks great to me, except for one thing: I think that we should write the corrected flags back to the data file. Given that 10.1 is already in GA status, we should consider our options carefully. My preference would be (1) below: (1) If we adjust 10.1.21 so that it writes back corrected flags for both old and new data files, then older 10.1.x would be unable to open the files (if compression, DATA_DIRECTORY or non-default innodb_page_size was used). (2) If we adjust 10.1.21 so that it writes correct flags for new data files (like the current patch does), then older 10.1.x would not be able to read those created-with-newer-version data files. (3) If we adjust 10.2 only, so that it writes the correct flags for new files and also adjusts the flags in old files, then we would seem to have a clear upgrade path. Whatever we choose, I would like to remove the flag-adjustment code from 10.3 or 10.4. This would mean that an upgrade (or import) directly from 10.1 is only possible if the problematic features (DATA_DIRECTORY, compression, non-standard innodb_page_size) were not used. Otherwise the upgrade would have to be done through 10.2.

            After some discussion, it seems that (3) would be the path of least surprise for users.
            This would mean that the work is to be done in MDEV-11202 only, and this ticket can be closed as ‘won’t fix’.

            marko Marko Mäkelä added a comment - After some discussion, it seems that (3) would be the path of least surprise for users. This would mean that the work is to be done in MDEV-11202 only, and this ticket can be closed as ‘won’t fix’.

            After some more discussion, we decided to go with (1), that is, fix this file format compatibility problem already in the 10.1 series, and keep the adjustment code also in 10.2, but possibly remove it from later release series.

            To allow downgrade from the fixed 10.1 to earlier (buggy) 10.1 releases, an innochecksum option will be implemented to convert tablespace flags to the buggy 10.1 format.

            marko Marko Mäkelä added a comment - After some more discussion, we decided to go with (1), that is, fix this file format compatibility problem already in the 10.1 series, and keep the adjustment code also in 10.2, but possibly remove it from later release series. To allow downgrade from the fixed 10.1 to earlier (buggy) 10.1 releases, an innochecksum option will be implemented to convert tablespace flags to the buggy 10.1 format.

            Read the current status and accept the direction this is going.

            jplindst Jan Lindström (Inactive) added a comment - Read the current status and accept the direction this is going.

            bb-10.1-mdev-11623 is rebased on the latest 10.1 branch.
            There are a few minor differences to the commits in the bb-10.1-jplindst branch:

            diff -I^@@ -I^index <(git diff origin/bb-10.1-mdev-11623{~,}) <(git diff origin/bb-10.1-jplindst{~16,})
            

            The above command displays 105 lines of output.

            marko Marko Mäkelä added a comment - bb-10.1-mdev-11623 is rebased on the latest 10.1 branch. There are a few minor differences to the commits in the bb-10.1-jplindst branch: diff -I^@@ -I^index <(git diff origin/bb-10.1-mdev-11623{~,}) <(git diff origin/bb-10.1-jplindst{~16,}) The above command displays 105 lines of output.

            Today, I did a test merge to 10.2 and pushed it to bb-10.2-mdev-11623.
            Given the amount of adjustments and conflict resolution needed, that merge probably should be reviewed as well.

            marko Marko Mäkelä added a comment - Today, I did a test merge to 10.2 and pushed it to bb-10.2-mdev-11623. Given the amount of adjustments and conflict resolution needed, that merge probably should be reviewed as well.

            Ok to push

            jplindst Jan Lindström (Inactive) added a comment - Ok to push

            In response to the failure https://gist.github.com/elenst/c0a11433d6146f21675f68f19021eb71
            I fixed two bugs in the doublewrite buffer code. Please review the latest commit in the bb-10.1-mdev-11623 branch.

            marko Marko Mäkelä added a comment - In response to the failure https://gist.github.com/elenst/c0a11433d6146f21675f68f19021eb71 I fixed two bugs in the doublewrite buffer code. Please review the latest commit in the bb-10.1-mdev-11623 branch.

            Ok to push.

            jplindst Jan Lindström (Inactive) added a comment - Ok to push.

            I filed MDEV-11799 for the non-flags-related fix of buf_dblwr_process().
            I think that we should fix that one separately already in 10.0, to make the InnoDB doublewrite buffer a more useful.

            marko Marko Mäkelä added a comment - I filed MDEV-11799 for the non-flags-related fix of buf_dblwr_process(). I think that we should fix that one separately already in 10.0, to make the InnoDB doublewrite buffer a more useful.

            The fix has been pushed to 10.1.21. I will keep this open until the fix is in 10.2 as well.

            marko Marko Mäkelä added a comment - The fix has been pushed to 10.1.21. I will keep this open until the fix is in 10.2 as well.

            The merge to 10.2 was challenging due to the refactoring of tablespace code and changes to tablespace discovery in crash recovery.

            marko Marko Mäkelä added a comment - The merge to 10.2 was challenging due to the refactoring of tablespace code and changes to tablespace discovery in crash recovery.

            People

              marko Marko Mäkelä
              jplindst Jan Lindström (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.