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

Tables created during backup may be missed after restore

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Duplicate
    • N/A
    • Backup
    • None

    Description

      The same test case passes with xtrabackup 2.4.5 and fails in current 10.1.22 (UPDATE 4-Apr-17 : the test passes with 2.3.6 and 2.3.7 as well)

      https://github.com/percona/percona-xtrabackup/blob/2.3/storage/innobase/xtrabackup/test/t/bug1291299.sh

      Needs investigation and may be converted to bug as I am not sure what priority should be and if this is really unexpected behavior or just different implementation of place where sync point is created.

      Attachments

        1. mariabackup-bug1291299.sh.err
          42 kB
          Andrii Nikitin
        2. mariabackup-ddl.sh.err
          28 kB
          Andrii Nikitin
        3. xtrabackup244-bug1291299.sh.err
          43 kB
          Andrii Nikitin
        4. xtrabackup244-ddl.sh.err
          59 kB
          Andrii Nikitin
        5. xtrabackup-bug1291299.sh.err
          43 kB
          Andrii Nikitin
        6. xtrabackup-ddl.sh.err
          59 kB
          Andrii Nikitin

        Issue Links

          is part of

          Task - A task that needs to be done. MDEV-16791 mariabackup : allow consistent backup, in presence of concurrent DDL, also without --lock-ddl-per-table

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-14095 Concurrent DDL can break xtrabackup-v2 SST in 10.2

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            anikitin Andrii Nikitin (Inactive) added a comment -

            Another test case and logs https://github.com/percona/percona-xtrabackup/blob/2.3/storage/innobase/xtrabackup/test/t/ddl.sh
            (2.4.4 passes on both tests as well)

            anikitin Andrii Nikitin (Inactive) added a comment - Another test case and logs https://github.com/percona/percona-xtrabackup/blob/2.3/storage/innobase/xtrabackup/test/t/ddl.sh (2.4.4 passes on both tests as well)
            wlad Vladislav Vaintroub added a comment -

            Does it pass with 2.3.6 ? this is our baseline

            wlad Vladislav Vaintroub added a comment - Does it pass with 2.3.6 ? this is our baseline
            anikitin Andrii Nikitin (Inactive) added a comment - - edited

            The test passes with following setups:
            Percona Xtrabackup 2.3.6 taking backup from Server MariaDB 10.1.22
            Percona Xtrabackup 2.3.7 taking backup from Server MariaDB 10.1.22
            Percona Xtrabackup 2.3.6 taking backup from Server of current bb-10.1-xtrabackup
            Percona Xtrabackup 2.3.7 taking backup from Server of current bb-10.1-xtrabackup

            And fails on the same Servers with mariabackup from bb-10.1-xtrabackup with message:
            bash: Cannot find backup/test/t1.ibd

            Maybe I am missing something, but I think this needs to be looked at by Marko or Jan

            anikitin Andrii Nikitin (Inactive) added a comment - - edited The test passes with following setups: Percona Xtrabackup 2.3.6 taking backup from Server MariaDB 10.1.22 Percona Xtrabackup 2.3.7 taking backup from Server MariaDB 10.1.22 Percona Xtrabackup 2.3.6 taking backup from Server of current bb-10.1-xtrabackup Percona Xtrabackup 2.3.7 taking backup from Server of current bb-10.1-xtrabackup And fails on the same Servers with mariabackup from bb-10.1-xtrabackup with message: bash: Cannot find backup/test/t1.ibd Maybe I am missing something, but I think this needs to be looked at by Marko or Jan
            anikitin Andrii Nikitin (Inactive) added a comment -

            Just for reference - it is still valid in current 10.1

            anikitin Andrii Nikitin (Inactive) added a comment - Just for reference - it is still valid in current 10.1
            anikitin Andrii Nikitin (Inactive) added a comment -

            One conceptual solution to the problem may be implementing MDEV-5336 LOCK TABLES FOR BACKUP and then --lock-ddl option in mariabackup

            anikitin Andrii Nikitin (Inactive) added a comment - One conceptual solution to the problem may be implementing MDEV-5336 LOCK TABLES FOR BACKUP and then --lock-ddl option in mariabackup
            marko Marko Mäkelä added a comment -

            Somewhat related to this is https://bugs.mysql.com/bug.php?id=71017.

            I think that the correct solution would be to implement a server-side backup command. With server-side backup, I do not see a need to prevent concurrent DDL operations. Newly created or renamed files would just be logged in the backup output stream.

            If the test really passes with xtrabackup 2.3, then we definitely need to do something about mariabackup.

            marko Marko Mäkelä added a comment - Somewhat related to this is https://bugs.mysql.com/bug.php?id=71017 . I think that the correct solution would be to implement a server-side backup command. With server-side backup, I do not see a need to prevent concurrent DDL operations. Newly created or renamed files would just be logged in the backup output stream. If the test really passes with xtrabackup 2.3, then we definitely need to do something about mariabackup.
            wlad Vladislav Vaintroub added a comment -

            Fixed with MDEV-16791

            wlad Vladislav Vaintroub added a comment - Fixed with MDEV-16791

            People

              marko Marko Mäkelä
              anikitin Andrii Nikitin (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              5 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.