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

mariadb-backup --backup --innodb-log-checkpoint-now may copy too much log

    XMLWordPrintable

Details

    • Related to performance

    Description

      I encountered this anomaly while adjusting the test mariabackup.unsupported_redo for MDEV-41152. I ended up implementing the following:

      diff --git a/mysql-test/suite/mariabackup/unsupported_redo.test b/mysql-test/suite/mariabackup/unsupported_redo.test
      index deb5b768802..cbfbcc43766 100644
      --- a/mysql-test/suite/mariabackup/unsupported_redo.test
      +++ b/mysql-test/suite/mariabackup/unsupported_redo.test
      @@ -57,6 +57,9 @@ ALTER TABLE t21 FORCE, ALGORITHM=INPLACE;
       --echo # Create partial backup (excluding table t21), Ignore the
       --echo # unsupported redo log for the table t21.
       
      +# Discard the FILE_CREATE record for creating t21
      +SET GLOBAL innodb_log_checkpoint_now=ON;
      +
       --disable_result_log
       exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf  --backup --parallel=10 "--tables-exclude=test.t21" --target-dir=$targetdir --innodb_log_checkpoint_now=1;
       --enable_result_log
      

      Note that the exec statement is supposed to execute the statement already, via the mariadb-backup option that had been introduced in MDEV-30000 and whose default value was changed in MDEV-36159.

      To my surprise, the t21.ibd would be recovered based on a FILE_CREATE record. It turns out that the request to force a log checkpoint is asynchronous, not synchronous:

      xtrabackup_backup_func()

      	if (innodb_log_checkpoint_now) {
      		msg("Initiating checkpoint");
      		if (mysql_send_query(mysql_connection,
      		    C_STRING_WITH_LEN("SET GLOBAL "
      				      "innodb_log_checkpoint_now=ON;"))) {
      			msg("initiating checkpoint failed");
      			return(false);
      		}
      	}
      // …
      	log_sys.create();
       
      	/* get current checkpoint_lsn */
      	{
      		log_sys.latch.wr_lock();
      		mysql_mutex_lock(&recv_sys.mutex);
      		dberr_t err = recv_sys.find_checkpoint();
      // …
      	/* try to wait for a log checkpoint, but do not fail if the
      	server does not support this */
      	if (innodb_log_checkpoint_now != false) {
      		mysql_read_query_result(mysql_connection);
      		msg("Finished waiting for checkpoint");
      	}
      

      According to the rr record traces that I created from the mariadbd process and the two mariadb-backup invocations (both for backup and prepare), the checkpoint request was submitted, but not fully executed before recv_sys.find_checkpoint() had determined that the latest checkpoint is the oldest one. We really need synchronous execution:

      xtrabackup_backup_func()

      	msg("cd to %s", mysql_real_data_home);
      	encryption_plugin_backup_init(mysql_connection);
      	if (innodb_log_checkpoint_now) {
      		xb_mysql_query(
      			mysql_connection,
      			"SET GLOBAL innodb_log_checkpoint_now=ON;",
      			false, false);
      	}
      

      Attachments

        Issue Links

          Activity

            People

              thiru Thirunarayanan Balathandayuthapani
              marko Marko Mäkelä
              Marko Mäkelä Marko Mäkelä
              Thirunarayanan Balathandayuthapani Thirunarayanan Balathandayuthapani
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0d
                  0d
                  Logged:
                  Time Spent - 1.5h
                  1.5h

                  Git Integration

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