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

rsync and mariabackup SST impossible if joiner has newer major version than donor

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.5, 10.6, 11.4
    • None
    • Galera SST
    • None

    Description

      Starting with MariaDB 10.5 Galera SST will fail with

      [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with Backup 10.4.34-MariaDB

      when using the rsync or mariabackup SST method, as both methods basically transfer a physical copy of the datadir, requiring recovery on the joiner side to get to a clean state.

      Not supporting recovery from earlier major versions prevents these two SST methods from working, only the mysqldump method can still function automatically.

      As a workaround one can do:

      • "manual SST" using Mariabackup, with both the --backup and --prepare steps performed on the donor side before copying over the clean prepared state over to the joiner
      • having new server version, but older mariabackup version, installed on the joiner

      This also affects rolling cluster upgrades to a new major release in cases where an upgraded node can't re-join using IST

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-31506 Updating cluster to a new major version Reports Upgrade after a crash is not supported with rsync sst

          • Major - Major loss of function.
          • Confirmed

          Task - A task that needs to be done. MDEV-31536 Galera mariadb-backup to work as SST between major versions

          • Major - Major loss of function.
          • Open
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-27437 Galera snapshot transfer fails to upgrade between some major versions

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            marko Marko Mäkelä added a comment -

            It turns out that MDEV-27437 had been filed for a quite similar problem.

            I remember suggesting at some point that there should be a special snapshot method that would prepare or recover from the non-logical backup on an intermediate node that runs the same software version as the donor. In that way, the joiner would be able to start with a logically empty write-ahead log.

            marko Marko Mäkelä added a comment - It turns out that MDEV-27437 had been filed for a quite similar problem. I remember suggesting at some point that there should be a special snapshot method that would prepare or recover from the non-logical backup on an intermediate node that runs the same software version as the donor. In that way, the joiner would be able to start with a logically empty write-ahead log.

            People

              Unassigned Unassigned
              hholzgra Hartmut Holzgraefe
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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