MDEV-25292 Atomic CREATE OR REPLACE TABLEbb-10.6-midenok-MDEV-25292

High level operation

  Two DDL chains are used for CREATE OR REPLACE execution:
  ddl_log_state_create (C) and ddl_log_state_rm (D).

  1. (C) Write DDL_LOG_RENAME_TABLE_ACTION from normal to backup;
  2. Rename table from normal to backup;
  3. D is replayed only if C is closed (D is linked as a slave to C);
  4. (D) Write DDL_LOG_DROP_ACTION of backup;
  5. (C) Write DDL_LOG_CREATE_TABLE_ACTION of new table;
  6. Create new table;
  7. (C) update XID;

  (In case of success)
  8. (C) close chain;
  9. (D) replay chain.

  (In case of error)
  8. (C) replay chain;
  9. (D) close chain.

Backup table for CREATE OR REPLACE

  - Instead of dropping the table, CREATE OR REPLACE renames table to
    a backup name. The rename is written into ddl_log_state_create.

  - CREATE TABLE without REPLACE is not affected by this commit.

  - Engines having HTON_EXPENSIVE_RENAME flag set are not affected by
    this commit.

  - The backup is done inside mysql_rm_table_no_locks() to be able to
    support ATOMIC DROP TABLE of multiple tables.

  - The ddl logging of CREATE and DROP are linked together. CREATE
    entries are executed before DROP entries.

  - In case of failed CREATE OR REPLACE ddl_log_state_create is
    replayed which restores original table.

  - In case of succeeded CREATE OR REPLACE ddl_log_state_rm is
    replayed which drops the backup (original table).

  - CREATE TABLE .. SELECT XID usage is fixed and now there is no need
    to log DROP TABLE via DDL_CREATE_TABLE_PHASE_LOG (see comments in
    do_postlock()). XID is now correctly updated so it disables
    DDL_LOG_DROP_TABLE_ACTION. Note that binary log is flushed at the
    final stage when the table is ready. So if we have XID in the
    binary log we don't need to drop the table.

  - Three variations of CREATE OR REPLACE handled:

    1. CREATE OR REPLACE TABLE t1 (..);
    2. CREATE OR REPLACE TABLE t1 LIKE t2;
    3. CREATE OR REPLACE TABLE t1 SELECT ..;

  - Test case uses 5 combinations for engines (aria, aria_notrans,
    myisam, ib, expensive_rename) and 2 combinations for binlog types
    (row, stmt). Combinations help to check differences between the
    results. Error failures are tested for the above three variations.

  - Triggers mechanism is unaffected by this change. This is tested in
    create_replace.test.

  - Triggers mechanism is unaffected which is tested.

  - LOCK TABLES is affected because RENAME TABLE cannot work on locked
    table. mysql_do_rename() (original do_rename()) can now work under
    locked_tables_mode.

On XID usage

  Like with all other atomic DDL operations XID is used to avoid
  inconsistency between master and slave in the case of a crash after
  binary log is written and before ddl_log_state_create is closed. On
  recovery XIDs are taken from binary log and corresponding DDL log
  events get disabled.  That is done by
  ddl_log_close_binlogged_events().

On linking two chains together

  Chains are executed in the ascending order of entry_pos of execute
  entries. But entry_pos assignment order is undefined: it may assign
  bigger number for the first chain and then smaller number for the
  second chain. So the execution order in that case will be reverse:
  second chain will be executed first.

0 files changed, 0 insertions, 0 deletions