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

Restoring a backup may result in garbage intermediate tables from DDL

Details

    Description

      MDEV-17567 and MDEV-25180 changed something in InnoDB startup. We forgot to adjust Mariabackup accordingly.

      Specifically, the command mariabackup --prepare --export is supposed to purge the history of old transactions, and also apply all logs.

      Starting with MDEV-25180, InnoDB no longer treats specially any tables whose names start with #sql. The only exception are table names that start with #sql-ib. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.

      The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during mariabackup --prepare --export, the execution would be aborted due to assertion failure.

      diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
      index db5c8524776..73f7a1aa248 100644
      --- a/storage/innobase/handler/ha_innodb.cc
      +++ b/storage/innobase/handler/ha_innodb.cc
      @@ -1954,6 +1954,7 @@ static int innodb_check_version(handlerton *hton, const char *path,
       static void innodb_ddl_recovery_done(handlerton*)
       {
         ut_ad(!ddl_recovery_done);
      +  ut_a(srv_operation != SRV_OPERATION_RESTORE_EXPORT);
         ut_d(ddl_recovery_done= true);
         if (!srv_read_only_mode && srv_operation == SRV_OPERATION_NORMAL &&
             srv_force_recovery < SRV_FORCE_NO_BACKGROUND)
      

      We must ensure that ha_signal_ddl_recovery_done() will be invoked. Should it for some reason be unacceptable to invoke ddl_log_execute_recovery() in mariabackup --prepare --export, then we would have to invoke special code that would drop all #sql- tables from InnoDB, before executing ha_signal_ddl_recovery_done(). In any case, we must somehow compensate for the change that was made in MDEV-25666.

      Note: Nothing must change in mariabackup outside --prepare --export. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.

      Attachments

        Issue Links

          Activity

            marko Marko Mäkelä created issue -
            marko Marko Mäkelä made changes -
            Field Original Value New Value
            marko Marko Mäkelä made changes -
            marko Marko Mäkelä made changes -
            marko Marko Mäkelä made changes -
            marko Marko Mäkelä made changes -
            Description MDEV-17567 and MDEV-25180 changed something in InnoDB startup. We forgot to adjust Mariabackup accordingly.

            Specifically, the command {{mariabackup --prepare --export}} is supposed to purge the history of old transactions, and also apply all logs.

            Starting with MDEV-25180, InnoDB now longer treats specially any tables whose names start with {{#sql}}. The only exception are table names that start with {{#sql-ib}}. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.

            The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during {{mariabackup --prepare --export}}, the execution would be aborted due to assertion failure.
            {code:diff}
            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index db5c8524776..73f7a1aa248 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -1954,6 +1954,7 @@ static int innodb_check_version(handlerton *hton, const char *path,
             static void innodb_ddl_recovery_done(handlerton*)
             {
               ut_ad(!ddl_recovery_done);
            + ut_a(srv_operation != SRV_OPERATION_RESTORE_EXPORT);
               ut_d(ddl_recovery_done= true);
               if (!srv_read_only_mode && srv_operation == SRV_OPERATION_NORMAL &&
                   srv_force_recovery < SRV_FORCE_NO_BACKGROUND)
            {code}
            We must ensure that {{ha_signal_ddl_recovery_done()}} will be invoked. Should it for some reason be unacceptable to invoke {{ddl_log_execute_recovery()}} in {{mariabackup --prepare --export}}, then we would have to invoke special code that would drop all {{#sql-}} tables from InnoDB, before executing {{ha_signal_ddl_recovery_done()}}. In any case, we must somehow compensate for the change that was made in MDEV-25666.

            Note: Nothing must change in {{mariabackup}} outside {{--prepare --export}}. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.
            MDEV-17567 and MDEV-25180 changed something in InnoDB startup. We forgot to adjust Mariabackup accordingly.

            Specifically, the command {{mariabackup --prepare --export}} is supposed to purge the history of old transactions, and also apply all logs.

            Starting with MDEV-25180, InnoDB now longer treats specially any tables whose names start with {{#sql}}. The only exception are table names that start with {{#sql-ib}}. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.

            The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during {{mariabackup --prepare --export}}, the execution would be aborted due to assertion failure.
            {code:diff}
            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index db5c8524776..73f7a1aa248 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -1954,6 +1954,7 @@ static int innodb_check_version(handlerton *hton, const char *path,
             static void innodb_ddl_recovery_done(handlerton*)
             {
               ut_ad(!ddl_recovery_done);
            + ut_a(srv_operation != SRV_OPERATION_RESTORE_EXPORT);
               ut_d(ddl_recovery_done= true);
               if (!srv_read_only_mode && srv_operation == SRV_OPERATION_NORMAL &&
                   srv_force_recovery < SRV_FORCE_NO_BACKGROUND)
            {code}
            We must ensure that {{ha_signal_ddl_recovery_done()}} will be invoked. Should it for some reason be unacceptable to invoke {{ddl_log_execute_recovery()}} in {{mariabackup --prepare --export}}, then we would have to invoke special code that would drop all {{#sql\-}} tables from InnoDB, before executing {{ha_signal_ddl_recovery_done()}}. In any case, we must somehow compensate for the change that was made in MDEV-25666.

            Note: Nothing must change in {{mariabackup}} outside {{--prepare --export}}. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.
            marko Marko Mäkelä made changes -
            serg Sergei Golubchik made changes -
            Description MDEV-17567 and MDEV-25180 changed something in InnoDB startup. We forgot to adjust Mariabackup accordingly.

            Specifically, the command {{mariabackup --prepare --export}} is supposed to purge the history of old transactions, and also apply all logs.

            Starting with MDEV-25180, InnoDB now longer treats specially any tables whose names start with {{#sql}}. The only exception are table names that start with {{#sql-ib}}. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.

            The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during {{mariabackup --prepare --export}}, the execution would be aborted due to assertion failure.
            {code:diff}
            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index db5c8524776..73f7a1aa248 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -1954,6 +1954,7 @@ static int innodb_check_version(handlerton *hton, const char *path,
             static void innodb_ddl_recovery_done(handlerton*)
             {
               ut_ad(!ddl_recovery_done);
            + ut_a(srv_operation != SRV_OPERATION_RESTORE_EXPORT);
               ut_d(ddl_recovery_done= true);
               if (!srv_read_only_mode && srv_operation == SRV_OPERATION_NORMAL &&
                   srv_force_recovery < SRV_FORCE_NO_BACKGROUND)
            {code}
            We must ensure that {{ha_signal_ddl_recovery_done()}} will be invoked. Should it for some reason be unacceptable to invoke {{ddl_log_execute_recovery()}} in {{mariabackup --prepare --export}}, then we would have to invoke special code that would drop all {{#sql\-}} tables from InnoDB, before executing {{ha_signal_ddl_recovery_done()}}. In any case, we must somehow compensate for the change that was made in MDEV-25666.

            Note: Nothing must change in {{mariabackup}} outside {{--prepare --export}}. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.
            MDEV-17567 and MDEV-25180 changed something in InnoDB startup. We forgot to adjust Mariabackup accordingly.

            Specifically, the command {{mariabackup --prepare --export}} is supposed to purge the history of old transactions, and also apply all logs.

            Starting with MDEV-25180, InnoDB no longer treats specially any tables whose names start with {{#sql}}. The only exception are table names that start with {{#sql-ib}}. It is the responsibility of the SQL layer's DDL log recovery to drop any such tables, in case the server was killed (or a backup was made) while a table-rebuilding DDL operation was in progress.

            The following patch proves that a regression was introduced. If the function (which would start the InnoDB purge of transaction history) would be invoked during {{mariabackup --prepare --export}}, the execution would be aborted due to assertion failure.
            {code:diff}
            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index db5c8524776..73f7a1aa248 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -1954,6 +1954,7 @@ static int innodb_check_version(handlerton *hton, const char *path,
             static void innodb_ddl_recovery_done(handlerton*)
             {
               ut_ad(!ddl_recovery_done);
            + ut_a(srv_operation != SRV_OPERATION_RESTORE_EXPORT);
               ut_d(ddl_recovery_done= true);
               if (!srv_read_only_mode && srv_operation == SRV_OPERATION_NORMAL &&
                   srv_force_recovery < SRV_FORCE_NO_BACKGROUND)
            {code}
            We must ensure that {{ha_signal_ddl_recovery_done()}} will be invoked. Should it for some reason be unacceptable to invoke {{ddl_log_execute_recovery()}} in {{mariabackup --prepare --export}}, then we would have to invoke special code that would drop all {{#sql\-}} tables from InnoDB, before executing {{ha_signal_ddl_recovery_done()}}. In any case, we must somehow compensate for the change that was made in MDEV-25666.

            Note: Nothing must change in {{mariabackup}} outside {{--prepare --export}}. We do not want to ruin incremental backups by executing actions that would generate InnoDB redo log records.
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Michael Widenius [ monty ]
            vlad.lesin Vladislav Lesin made changes -
            monty Michael Widenius made changes -
            Assignee Michael Widenius [ monty ] Sergei Golubchik [ serg ]
            marko Marko Mäkelä made changes -
            Component/s Storage Engine - InnoDB [ 10129 ]
            Assignee Sergei Golubchik [ serg ] Vladislav Vaintroub [ wlad ]
            Summary mariabackup --prepare --export fails to run some actions Restoring a backup may result in garbage intermediate tables from DDL
            marko Marko Mäkelä made changes -
            Assignee Vladislav Vaintroub [ wlad ] Marko Mäkelä [ marko ]
            marko Marko Mäkelä made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            marko Marko Mäkelä made changes -
            Assignee Marko Mäkelä [ marko ] Vladislav Vaintroub [ wlad ]
            Status In Progress [ 3 ] In Review [ 10002 ]
            marko Marko Mäkelä made changes -
            issue.field.resolutiondate 2021-06-17 10:47:50.0 2021-06-17 10:47:50.346
            marko Marko Mäkelä made changes -
            Fix Version/s 10.6.2 [ 25800 ]
            Fix Version/s 10.6 [ 24028 ]
            Assignee Vladislav Vaintroub [ wlad ] Marko Mäkelä [ marko ]
            Resolution Fixed [ 1 ]
            Status In Review [ 10002 ] Closed [ 6 ]
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            marko Marko Mäkelä made changes -
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 122448 ] MariaDB v4 [ 159361 ]
            marko Marko Mäkelä made changes -

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.