mariadb/mysql-test/suite/binlog/t/binlog_tmp_table.test
Monty e62dc52420 MDEV-25292 Atomic CREATE OR REPLACE TABLE
Atomic CREATE OR REPLACE allows to keep an old table intact if the
command fails or during the crash. That is done by renaming the
original table to temporary name, as a backup and restoring it if the
CREATE fails. When the command is complete and logged the backup
table is deleted.

Atomic replace algorithm

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

  1. (C) Log rename of ORIG to TMP table (Rename TMP to original).
  2. Rename orignal to TMP.
  3. (C) Log CREATE_TABLE_ACTION of ORIG (drops ORIG);
  4. Do everything with ORIG (like insert data)
  5. (D) Log drop of TMP
  6. Write query to binlog (this marks (C) to be closed in
     case of failure)
  7. Execute drop of TMP through (D)
  8. Close (C) and (D)

  If there is a failure before 6) we revert the changes in (C)
  Chain (D) is only executed if 6) succeded (C is closed on
  crash recovery).

Foreign key errors will be found at the 1) stage.

Additional notes

  - CREATE TABLE without REPLACE and temporary tables is not affected
    by this commit.
    set @@drop_before_create_or_replace=1 can be used to
    get old behaviour where existing tables are dropped
    in CREATE OR REPLACE.

  - CREATE TABLE is reverted if binlogging the query fails.

  - Engines having HTON_EXPENSIVE_RENAME flag set are not affected by
    this commit. Conflicting tables marked with this flag will be
    deleted with CREATE OR REPLACE.

  - Replication execution is not affected by this commit.
    - Replication will first drop the conflicting table and then
      creating the new one.

  - 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 6 combinations for engines (aria, aria_notrans,
    myisam, ib, lock_tables, 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.

  - expensive_rename tests CREATE OR REPLACE without atomic
    replace. The effect should be the same as with the old behaviour
    before this commit.

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

  - LOCK TABLES is affected. Lock restoration must be done after new
    table is created or TMP is renamed back to ORIG

  - Moved ddl_log_complete() from send_eof() to finalize_ddl(). This
    checkpoint was not executed before for normal CREATE TABLE but is
    executed now.

  - CREATE TABLE will now rollback also if writing to the binary
    logging failed. See rpl_gtid_strict.test

backup ddl log changes

- In case of a successfull CREATE OR REPLACE we only log
  the CREATE event, not the DROP TABLE event of the old table.

ddl_log.cc changes

  ddl_log_execute_action() now properly return error conditions.
  ddl_log_disable_entry() added to allow one to disable one entry.
  The entry on disk is still reserved until ddl_log_complete() is
  executed.

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.

  To avoid that we link one chain to another. While the base chain
  (ddl_log_state_create) is active the secondary chain
  (ddl_log_state_rm) is not executed. That is: only one chain can be
  executed in two linked chains.

  The interface ddl_log_link_chains() was defined in "MDEV-22166
  ddl_log_write_execute_entry() extension".

Atomic info parameters in HA_CREATE_INFO

  Many functions in CREATE TABLE pass the same parameters. These
  parameters are part of table creation info and should be in
  HA_CREATE_INFO (or whatever). Passing parameters via single
  structure is much easier for adding new data and
  refactoring.

InnoDB changes
  Added ha_innobase::can_be_renamed_to_backup() to check if
  a table with foreign keys can be renamed.

Aria changes:
- Fixed issue in Aria engine with CREATE + locked tables
  that data was not properly commited in some cases in
  case of crashes.

Known issues:
- InnoDB tables with foreign key definitions are not fully supported
  with atomic create and replace:
  - ha_innobase::can_be_renamed_to_backup() can detect some cases
    where InnoDB does not support renaming table with foreign key
    constraints.  In this case MariaDB will drop the old table before
    creating the new one.
    The detected cases are:
    - The new and old table is using the same foreign key constraint
      name.
    - The old table has self referencing constraints.
  - If the old and new table uses the same name for a constraint the
    create of the new table will fail. The orignal table will be
    restored in this case.
  - The above issues will be fixed in a future commit.
- CREATE OR REPLACE TEMPORARY table is not full atomic. Any conflicting
  table will always be dropped before creating a new one. (Old behaviour).
2025-03-18 18:28:16 +01:00

167 lines
4.4 KiB
Text

# ==== Purpose ====
#
# Test if statements used temporary tables are binlogged correctly
#
# ==== Method ====
#
# Use two connections, use temporary tables on both of them, and by
# switching connections between statements, the test can check if the
# statements are logged with the correct thread id.
#
# The statements current tested include:
# CREATE TEMPORARY TABLE
# CREATE TEMPORARY TABLE LIKE
# INSERT
# REPLACE
# UPDATE
# INSERT SELECT
# TRUNCATE
#
# Note: When adding new query statements, please add them between the
# two 'flush logs'. And aslo please make sure the connection is
# switched between each statement.
#
# ==== Related bugs ====
#
# BUG#35583 mysqlbinlog replay fails with ERROR 1146 when temp tables are used
#
source include/have_log_bin.inc;
source include/have_binlog_format_mixed_or_statement.inc;
RESET MASTER;
--disable_query_log
CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT");
--enable_query_log
connect (master,127.0.0.1,root,,test,$MASTER_MYPORT,);
connect (master1,127.0.0.1,root,,test,$MASTER_MYPORT,);
create table foo (a int);
flush logs;
connection master;
create temporary table tmp1_foo like foo;
connection master1;
create temporary table tmp2_foo (a int);
connection master;
insert into tmp1_foo values (1), (2), (3), (4);
connection master1;
replace into tmp2_foo values (1), (2), (3), (4);
connection master;
update tmp1_foo set a=2*a-1;
connection master1;
update tmp2_foo set a=2*a;
connection master;
delete from tmp1_foo where a < 5;
connection master1;
delete from tmp2_foo where a < 5;
--disable_warnings
connection master;
insert into foo select * from tmp1_foo;
connection master1;
insert into foo select * from tmp2_foo;
--enable_warnings
connection master;
truncate table tmp1_foo;
connection master1;
truncate table tmp2_foo;
let $binlog_file= query_get_value(SHOW MASTER STATUS, File, 1);
flush logs;
connection default;
select * from foo;
# prepare for the replay
drop table foo;
create table foo (a int);
# replay from binary log
let $MYSQLD_DATADIR= `select @@datadir`;
exec $MYSQL_BINLOG $MYSQLD_DATADIR/$binlog_file | $MYSQL;
select * from foo;
# clean up
drop table foo;
#################################################################
# BUG#51226
#################################################################
RESET MASTER;
-- let $dbname=b51226
connect (con1,localhost,root,,test,$MASTER_MYPORT,$MASTER_MYSOCK);
connect (con2,localhost,root,,test,$MASTER_MYPORT,$MASTER_MYSOCK);
#
# action: on con1 create the database and the tmp table
#
-- connection con1
-- eval create database $dbname
-- eval use $dbname
set @@binlog_format="statement";
create temporary table t1(i int);
#
# action: on con1 create the tmp table
#
-- connection con2
-- eval use $dbname
set @@binlog_format="statement";
create temporary table t1(i int);
# action: at this point, the last event binlogged contains the
# pseudo_thread_id from con2. So now we switch to con1, issue
# a statement that fails and close the connection (which logs
# implicitely a DROP TEMPORARY TABLE).
#
# Before the patch this would not log con1's pseudo_thread_id
# because the failing statement would reset THD context
# (unsetting the thread_specific_used flag, and consequently,
# causing the DROP event to be logged without pseudo_thread_id
# in its header).
-- connection con1
-- error 1050
create temporary table t1(i int);
-- disconnect con1
-- connection default
if (`SELECT FIND_IN_SET(@@BINLOG_FORMAT,@@CREATE_TEMPORARY_TABLE_BINLOG_FORMATS) > 0`)
{
-- let $wait_binlog_event= DROP
-- source include/wait_for_binlog_event.inc
}
# action: insert in the t1. This would cause the the test to fail,
# because when replaying the binlog the previous implicit drop
# temp table would have been executed under the wrong
# pseudo_thread_id, dropping the tmp table on con2.
-- connection con2
insert into t1 values(1);
-- disconnect con2
-- connection default
if (`SELECT FIND_IN_SET(@@BINLOG_FORMAT,@@CREATE_TEMPORARY_TABLE_BINLOG_FORMATS) > 0`)
{
-- let $wait_binlog_event= DROP
-- source include/wait_for_binlog_event.inc
}
-- eval DROP DATABASE $dbname
FLUSH LOGS;
# assertion: assert that when replaying the binary log will succeed,
# instead of failing with "Table 'XXX.YYY' doesn't exist"
-- let $MYSQLD_DATADIR= `select @@datadir`
-- exec $MYSQL_BINLOG $MYSQLD_DATADIR/master-bin.000001 | $MYSQL