Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
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
- relates to
-
MDEV-5336 Implement BACKUP STAGE for safe external backups
-
- Closed
-
-
MDEV-14992 BACKUP SERVER to mounted file system
-
- In Progress
-
-
MDEV-17567 Atomic DDL
-
- Closed
-
-
MDEV-38304 Innodb Binlog to be Stored in Archived Redo Log
-
- Open
-
-
MDEV-41705 Atomic DROP TABLE is not crash-safe on power loss: the link to the DROP TABLE entry in ddl_recovery.log is not synced, so after a power failure during DROP TABLE the .frm survives while InnoDB has dropped the table
-
- Confirmed
-