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

mariabackup: position saved in xtrabackup_binlog_info is incorrect for replication

Details

    Description

      It appears that mariabackup no longer updates xtrabackup_binlog_info file after completing prepare phase. The position in the file is therefore incorrect and can't be used to set up replication after a restore. The position reported in the prepare phase log is correct, it's just that the file is not updated.

      This is critical as a lot of DBAs and tools use the content of this file to set up replication, manually or automatically. Please fix it ASAP!

      Thank you.

      Rick

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25136 Mariabackup crash with InnoDB: Assertion failure in file /.../extra/mariabackup/xtrabackup.cc line 875

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-18917 Don't create xtrabackup_binlog_pos_innodb with Mariabackup

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-21611 mariabackup should update binlog position in InnoDB during prepare

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Task - A task that needs to be done. MDEV-26391 mariabackup always triggers node desync

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35080 mariabackup: position saved in xtrabackup_binlog_info is incorrect for replication

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            View 8 older comments
            rpizzi Rick Pizzi (Inactive) added a comment -

            GeoffMontee the position in xtrabackup_binlog_info is incorrect, see my test case above, The correct one is the one that prepare spits out. I keep hearing that this position taken at backup shouldn't change after a prepare but I believe that's not true.

            rpizzi Rick Pizzi (Inactive) added a comment - GeoffMontee the position in xtrabackup_binlog_info is incorrect, see my test case above, The correct one is the one that prepare spits out. I keep hearing that this position taken at backup shouldn't change after a prepare but I believe that's not true.
            rpizzi Rick Pizzi (Inactive) added a comment -

            So I have tried the same test above with Percona Xtrabackup 2.4.20 and MariaDB 10.2.32 and the position stays the same.
            So, I will change this bug title to "position saved in xtrabackup_binlog_info is incorrect for replication".

            rpizzi Rick Pizzi (Inactive) added a comment - So I have tried the same test above with Percona Xtrabackup 2.4.20 and MariaDB 10.2.32 and the position stays the same. So, I will change this bug title to "position saved in xtrabackup_binlog_info is incorrect for replication".
            vlad.lesin Vladislav Lesin added a comment - - edited

            There is at least one place where Galera's code bypasses backup locks during DDL execution came from another node, what can cause the effect when binlog position is changed under backup BLOCK_COMMIT lock: MDEV-25136.

            vlad.lesin Vladislav Lesin added a comment - - edited There is at least one place where Galera's code bypasses backup locks during DDL execution came from another node, what can cause the effect when binlog position is changed under backup BLOCK_COMMIT lock: MDEV-25136 .
            serg Sergei Golubchik added a comment -

            As the discussion above shows, there seems to be an issue in wsrep code ignoring BACKUP STAGE BLOCK_COMMIT mdl lock.

            serg Sergei Golubchik added a comment - As the discussion above shows, there seems to be an issue in wsrep code ignoring BACKUP STAGE BLOCK_COMMIT mdl lock.
            lpacheco Leandro Pacheco (Inactive) added a comment -

            Opened a PR (https://github.com/MariaDB/server/pull/1877) which modifies BACKUP STAGE BLOCK_DDL/BLOCK_COMMIT to behave as FTWRL when wsrep is enabled: replication is paused in the node until BACKUP STAGE END.

            lpacheco Leandro Pacheco (Inactive) added a comment - Opened a PR ( https://github.com/MariaDB/server/pull/1877 ) which modifies BACKUP STAGE BLOCK_DDL/BLOCK_COMMIT to behave as FTWRL when wsrep is enabled: replication is paused in the node until BACKUP STAGE END.

            People

              jplindst Jan Lindström (Inactive)
              rpizzi Rick Pizzi (Inactive)
              Votes:
              6 Vote for this issue
              Watchers:
              10 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.