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

Index Corruption on Database Restore

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Cannot Reproduce
    • 10.6.18
    • 10.6.21
    • Backup
    • Ubuntu 22.04.5
      mysql Ver 15.1 Distrib 10.6.18-MariaDB, for debian-linux-gnu (x86_64)

    Description

      I have a logical database backup that causes a corrupted index error on restore. I've narrowed down the problem to one table and one index in that table.

      Here is a Google Drive link of a tgz containing a trimmed down version of the backup, which should allow you to recreate the issue on restoring to an empty database. This also includes the contents of the error log at the time of the error and the cnf files I'm using.

      The table name in the backup is AuditLog, and it seems that the index "uri_index" is causing the problem. If I manually remove the uri_index from the backup file, the restore works as expected.

      Let me know if any more information would be useful.

      Attachments

        Issue Links

          Activity

            Hi! Could you test whether this is reproducible with MariaDB Server 10.6.21, which was just released this week?

            marko Marko Mäkelä added a comment - Hi! Could you test whether this is reproducible with MariaDB Server 10.6.21, which was just released this week?
            coreyoss Corey Smith added a comment -

            Yes! I will give it a try and let you know what happens. Thanks!

            coreyoss Corey Smith added a comment - Yes! I will give it a try and let you know what happens. Thanks!
            coreyoss Corey Smith added a comment -

            Hi Marko, I tested on 10.6.21 and it works fine on that version.

            coreyoss Corey Smith added a comment - Hi Marko, I tested on 10.6.21 and it works fine on that version.

            Thank you, coreyoss, I’m glad to read that! Unfortunately, I don’t think it is feasible to find out which exact change fixed this. The performance measures of ROW_FORMAT=COMPRESSED (including the compression factor) is extremely unpredictable and timing sensitive, depending on when the purge of committed transaction history has a chance to run in secondary indexes. Because the fix of MDEV-30882 is not perfect, I can’t with a good conscience claim that this bug has been fixed. Let me for now close it as "cannot reproduce."

            marko Marko Mäkelä added a comment - Thank you, coreyoss , I’m glad to read that! Unfortunately, I don’t think it is feasible to find out which exact change fixed this. The performance measures of ROW_FORMAT=COMPRESSED (including the compression factor) is extremely unpredictable and timing sensitive, depending on when the purge of committed transaction history has a chance to run in secondary indexes. Because the fix of MDEV-30882 is not perfect, I can’t with a good conscience claim that this bug has been fixed. Let me for now close it as "cannot reproduce."
            coreyoss Corey Smith added a comment -

            Sounds good! We'll just upgrade to 10.6.21 and move on. Thank you!

            coreyoss Corey Smith added a comment - Sounds good! We'll just upgrade to 10.6.21 and move on. Thank you!

            People

              marko Marko Mäkelä
              coreyoss Corey Smith
              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.