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

Option to write DDL recovery log to InnoDB

    XMLWordPrintable

Details

    Description

      The title of MDEV-17567 is Atomic DDL.

      Like we already know, some operations are not atomic. One example is DROP DATABASE, which is being logged and recovered as a sequence of DROP TABLE operations.

      The following test case, created by saahil while testing MDEV-14492 BACKUP SERVER, demonstrates one deficiency:

      --source include/have_innodb.inc
      --source include/have_debug_sync.inc
      CREATE DATABASE d1;
      CREATE TABLE d1.t1 (a INT) ENGINE=InnoDB;
      SET GLOBAL innodb_log_checkpoint_now=ON;
      --let $target= $MYSQLTEST_VARDIR/tmp/backup
      --connect ddl,localhost,root
      SET DEBUG_SYNC='rm_table_no_locks_before_delete_table SIGNAL dropping WAIT_FOR go';
      --send DROP DATABASE d1
      --connection default
      SET DEBUG_SYNC='now WAIT_FOR dropping';
      --connect backup,localhost,root
      --send_eval BACKUP SERVER TO '$target'
      --connection default
      --let $wait_condition= SELECT COUNT(*)=1 FROM information_schema.processlist WHERE state='Waiting for backup lock'
      --source include/wait_condition.inc
      SET DEBUG_SYNC='now SIGNAL go';
      --connection ddl
      --reap
      --connection backup
      --reap
      --connection default
      --exec cat $MYSQLTEST_VARDIR/my.cnf >> $target/backup.cnf
      --let $restart_parameters= --defaults-file=$target/backup.cnf --datadir=$target
      --source include/restart_mysqld.inc
      --let $n= query_get_value(SELECT COUNT(*) AS n FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME='d1', n, 1)
      if ($n)
      {
        --die A database dropped before the backup snapshot exists, empty, in the restored server
      }
      --let $restart_parameters=
      --source include/restart_mysqld.inc
      --rmdir $target
      

      The backup will be recovered with no tables in the schema d1. But, the schema d1 exists in the backup, even though it should not if DROP DATABASE is supposed to be an atomic DDL operation.

      I believe that the correct way to fix and other operations this is to implement an option where no @@log-ddl-recovery files (default name: ddl_recovery.log are being created or written, but all DDL operations will be covered by true write-ahead-logging in a persistent storage engine, such as InnoDB. The log records should include also the payload, for example, for creating db.opt files or files whose names end in .frm.

      The true DDL WAL should allow an InnoDB-only backup to be made without acquiring any locks whatsoever. (For binlog_storage_engine=innodb (MDEV-34705) a backup solution should be implemented in MDEV-38304.)

      Currently, MDEV-14992 is based on the MDEV-5336 backup locks.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              marko Marko Mäkelä
              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 - 1h
                  1h

                  Git Integration

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