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

mariadb-backup fails to preserve innodb_encrypt_tables=1

Details

    Description

      While testing MDEV-33383, mleich produced rr replay traces of a 10.5 server that was being backed up, as well as the mariadb-backup processes that made and prepared the backup, and another server process that crashed due to a corrupted page when starting on the prepared backup.

      Some painstaking analysis revealed the reason for the corruption: The parameter innodb_encrypt_tables=1 is not being copied to the backup-my.cnf file, neither in encryption_plugin_backup_init(), nor in write_backup_config_file(). The configuration parameter innodb_encrypt_log is being copied, ever since MDEV-9566 was implemented.

      It looks like neither the settings innodb_encrypt_log=1 nor innodb_encrypt_tables=1 will be restored from the backup-my.cnf} file during {{mariadb-backup --prepare. The setting innodb_encrypt_log will be persisted via the log file format, but innodb_encrypt_tables would only be recoverable from the configuration file.

      Because of the incorrect default setting innodb_encrypt_tables=0 that is in effect during mariadb-backup --prepare, the backup will be corrupted: Those data pages on which some log was applied could be stored unencrypted, while others would be stored encrypted from the server.

      As far as I understand, there may be an additional design problem that when SET GLOBAL innodb_encrypt_tables=... is executed during or between backup runs, no consistent backups can be created.

      Attachments

        Issue Links

          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33334 mariadb-backup fails to preserve innodb_encrypt_tables

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

          Task - A task that needs to be done. MDEV-9566 Add xtrabackup tool to MariaDB 10.1

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-25083 MariaBackup doesn't work if InnoDB runs with strict_none or strict_innodb

          • Major - Major loss of function.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33334 mariadb-backup fails to preserve innodb_encrypt_tables

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33383 fts query crashes in fts_query_calculate_ranking()

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

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            I am able to correctly restore the problematic backup by applying the following patch, which would hard-wire innodb_encrypt_tables=ON in mariadb-backup --prepare:

            diff --git a/extra/mariabackup/xtrabackup.cc b/extra/mariabackup/xtrabackup.cc
            		 
            index 5f6ec1b0c0c..0226ad40473 100644
            		 
            --- a/extra/mariabackup/xtrabackup.cc
            		 
            +++ b/extra/mariabackup/xtrabackup.cc
            		 
            @@ -6143,6 +6143,7 @@ static bool xtrabackup_prepare_func(char** argv)
            		 
             		goto error_cleanup;
            		 
             	}
            		 
             
            +	srv_encrypt_tables = true;
            		 
             	fil_system.freeze_space_list = 0;
            		 
             
             	msg("Starting InnoDB instance for recovery.");

            I think that this needs to be fixed in 3 places in mariadb-backup:

            1. Reading the parameter from the server in encryption_plugin_backup_init()
            2. Writing the parameter to backup-my.cnf in write_backup_config_file()
            3. Restoring the parameter from backup-my.cnf during --prepare
            marko Marko Mäkelä added a comment - I am able to correctly restore the problematic backup by applying the following patch, which would hard-wire innodb_encrypt_tables=ON in mariadb-backup --prepare : diff --git a/extra/mariabackup/xtrabackup.cc b/extra/mariabackup/xtrabackup.cc index 5f6ec1b0c0c..0226ad40473 100644 --- a/extra/mariabackup/xtrabackup.cc +++ b/extra/mariabackup/xtrabackup.cc @@ -6143,6 +6143,7 @@ static bool xtrabackup_prepare_func(char** argv) goto error_cleanup; } + srv_encrypt_tables = true; fil_system.freeze_space_list = 0; msg("Starting InnoDB instance for recovery."); I think that this needs to be fixed in 3 places in mariadb-backup : Reading the parameter from the server in encryption_plugin_backup_init() Writing the parameter to backup-my.cnf in write_backup_config_file() Restoring the parameter from backup-my.cnf during --prepare
            marko Marko Mäkelä added a comment -

            This was also reproduced by a user in MDEV-33334.

            marko Marko Mäkelä added a comment - This was also reproduced by a user in MDEV-33334 .

            People

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