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

Restore of database from MariaDB 10.3.17 to MariaDB 10.2.22 fails

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • 10.2.22, 10.3.17
    • N/A
    • None
    • MariaDB 10.3.17 was installed on RHEL 8.2, x86, 64 bit system
      MariaDB 10.2.22 was installed on SLES15SP1, ppc64le system

    Description

      Backup was taken on 10.3.17 MariaDB - copied /var/lib/mysql directory
      Restored on 10.2.22 MAriaDB - pasted the backed up directory contents.

      Restarted mariadb db service using the below command,
      systemctl restart mariadb

      This method of backup/restore of mariadb databases worked in our product. But in this particular scenario we see that once the mariadb service is restarted, the table updates fail. Below are the logs & other information.

      -----------------------------------------------------------------------------------------------
      /var/log/mysql/mysqld.log
      2020-07-23 11:53:46 140736164823024 [ERROR] InnoDB: Transaction id 16405 associated with recordCOMPACT RECORD(info_bits=0, 2 fields):

      {[4] (0x80000001),[4] (0x80000001)}

      in index `local_user_id` of table `keystone`.`password` is greater than the global counter 6661! The table is corrupted.
      2020-07-23 11:53:46 0x7fffb11c7ff0 InnoDB: Assertion failure in file /home/abuild/rpmbuild/BUILD/mariadb-10.2.22/storage/innobase/trx/trx0undo.cc line 1513
      InnoDB: Failing assertion: mach_read_from_2(undo_page + TRX_UNDO_PAGE_HDR + TRX_UNDO_PAGE_TYPE) == TRX_UNDO_UPDATE
      InnoDB: We intentionally generate a memory trap.
      InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
      InnoDB: If you get repeated assertion failures or crashes, even
      InnoDB: immediately after the mysqld startup, there may be
      InnoDB: corruption in the InnoDB tablespace. Please refer to
      InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
      InnoDB: about forcing recovery.
      200723 11:53:46 [ERROR] mysqld got signal 6 ;
      This could be because you hit a bug. It is also possible that this binary
      or one of the libraries it was linked against is corrupt, improperly built,
      or misconfigured. This error can also be caused by malfunctioning hardware.

      To report this bug, see https://mariadb.com/kb/en/reporting-bugs
      -----------------------------------------------------------------------------------------------

      MariaDB [(none)]> CHECK TABLE keystone.password;
      ---------------------------------------------------------------------------------------+

      Table Op Msg_type Msg_text

      ---------------------------------------------------------------------------------------+

      keystone.password check Warning InnoDB: The B-tree of index local_user_id is corrupted.
      keystone.password check error Corrupt

      ---------------------------------------------------------------------------------------+

      One more thing which was observed was is frequent connection errors.
      MariaDB [(none)]> select * from keystone.password;
      ERROR 2006 (HY000): MySQL server has gone away
      No connection. Trying to reconnect...
      ERROR 2013 (HY000): *Lost connection to MySQL server at 'handshake: reading inital *communication packet', system error: 104
      ERROR: Can't connect to the server

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              abhi1234 Abhishek
              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.