mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-04-15 11:45:32 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
mariadb/mysql-test/suite/binlog/include/binlog.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

437 lines
12 KiB
Text
Raw Permalink Blame History

#
# misc binlogging tests that do not require a slave running
#
-- source include/have_log_bin.inc
-- source include/not_embedded.inc
-- source include/have_innodb.inc
--disable_warnings
drop table if exists t1, t2;
--enable_warnings
reset master;
create table t1 (a int) engine=innodb;
create table t2 (a int) engine=innodb;
begin;
insert t1 values (5);
commit;
begin;
insert t2 values (5);
commit;
# first COMMIT must be Query_log_event, second - Xid_log_event
source include/show_binlog_events.inc;
drop table t1,t2;
#
# binlog rotation after one big transaction
#
reset master;
let $1=100;
create table t1 (n int) engine=innodb;
begin;
--disable_query_log
while ($1)
{
eval insert into t1 values($1 + 4);
dec $1;
}
--enable_query_log
commit;
# Make sure binlog checkpoint is logged before DROP TABLE to avoid random
# result difference.
--source include/wait_for_binlog_checkpoint.inc
drop table t1;
--source include/show_binlog_events.inc
--let $binlog_file= query_get_value(SHOW MASTER STATUS, File, 1)
--source include/show_binlog_events.inc
--let $binlog_file=
#
# Bug#22540 - Incorrect value in column End_log_pos of
# SHOW BINLOG EVENTS using InnoDB
#
# the following tests will show that certain queries now return
# absolute offsets (from binlog start, rather than relative to
# the beginning of the current transaction). under what
# conditions it should be allowed / is sensible to put the
# slider into the middle of a transaction is not our concern
# here; we just guarantee that if and when it's done, the
# user has valid offsets to use. if the setter function still
# wants to throw a "positioning into middle of transaction"
# warning, that's its prerogative and handled elsewhere.
set @ac = @@autocommit;
# first show this to work for SHOW BINLOG EVENTS
set autocommit= 0;
reset master;
create table t1(n int) engine=innodb;
begin;
insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);
commit;
drop table t1;
--source include/show_binlog_events.inc
# now show that nothing breaks if we need to read from the cache more
# than once, resulting in split event-headers
set @bcs = @@binlog_cache_size;
set global binlog_cache_size=4096;
reset master;
create table t1 (a int, b char(255)) engine=innodb;
flush global status;
show status like "binlog_cache_use";
let $1=100;
disable_query_log;
begin;
while ($1)
{
eval insert into t1 values( $1, 'just to fill void to make transaction occupying at least two buffers of the trans cache' );
dec $1;
}
commit;
--echo *** the following must show the counter value = 1 ***
show status like "binlog_cache_use";
enable_query_log;
--source include/show_binlog_events.inc
drop table t1;
set global binlog_cache_size=@bcs;
set session autocommit = @ac;
#
# Bug#33798: prepared statements improperly handle large unsigned ints
#
--disable_warnings
drop table if exists t1;
--enable_warnings
reset master;
create table t1 (a bigint unsigned, b bigint(20) unsigned);
prepare stmt from "insert into t1 values (?,?)";
set @a= 9999999999999999;
set @b= 14632475938453979136;
execute stmt using @a, @b;
deallocate prepare stmt;
drop table t1;
--source include/show_binlog_events.inc
#
# Bug #39182: Binary log producing incompatible character set query from
# stored procedure.
#
reset master;
CREATE DATABASE bug39182 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
USE bug39182;
CREATE TABLE t1 (a VARCHAR(255) COLLATE utf8_unicode_ci)
DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
DELIMITER //;
CREATE PROCEDURE p1()
BEGIN
DECLARE s1 VARCHAR(255);
SET s1= "test";
CREATE TEMPORARY TABLE tmp1
SELECT * FROM t1 WHERE a LIKE CONCAT("%", s1, "%");
SELECT
COLLATION(NAME_CONST('s1', _utf8'test')) c1,
COLLATION(NAME_CONST('s1', _utf8'test' COLLATE utf8_unicode_ci)) c2,
COLLATION(s1) c3,
COERCIBILITY(NAME_CONST('s1', _utf8'test')) d1,
COERCIBILITY(NAME_CONST('s1', _utf8'test' COLLATE utf8_unicode_ci)) d2,
COERCIBILITY(s1) d3;
DROP TEMPORARY TABLE tmp1;
END//
DELIMITER ;//
CALL p1();
source include/show_binlog_events.inc;
DROP PROCEDURE p1;
DROP TABLE t1;
DROP DATABASE bug39182;
USE test;
#
# Bug#35383: binlog playback and replication breaks due to
# name_const substitution
#
DELIMITER //;
CREATE PROCEDURE p1(IN v1 INT)
BEGIN
CREATE TABLE t1 SELECT v1;
DROP TABLE t1;
END//
CREATE PROCEDURE p2()
BEGIN
DECLARE v1 INT;
CREATE TABLE t1 SELECT v1+1;
DROP TABLE t1;
END//
CREATE PROCEDURE p3(IN v1 INT)
BEGIN
CREATE TABLE t1 SELECT 1 FROM DUAL WHERE v1!=0;
DROP TABLE t1;
END//
CREATE PROCEDURE p4(IN v1 INT)
BEGIN
DECLARE v2 INT;
CREATE TABLE t1 SELECT 1, v1, v2;
DROP TABLE t1;
CREATE TABLE t1 SELECT 1, v1+1, v2;
DROP TABLE t1;
END//
DELIMITER ;//
CALL p1(1);
CALL p2();
CALL p3(0);
CALL p4(0);
DROP PROCEDURE p1;
DROP PROCEDURE p2;
DROP PROCEDURE p3;
DROP PROCEDURE p4;
--echo End of 5.0 tests
# Test of a too big SET INSERT_ID.
# This should generate an error and should not be put in binlog
# We look at the binlog further down with SHOW BINLOG EVENTS.
reset master;
create table t1 (id tinyint auto_increment primary key);
insert into t1 values(5);
set insert_id=128;
--error HA_ERR_AUTOINC_ERANGE
insert into t1 values(null) /* Not binlogged */;
# The followin insert ignore will be put in binlog
set insert_id=128;
insert ignore into t1 values(null) /* Insert 128 */;
# Insert with duplicate key error should not go into binglo
set insert_id=5;
--error ER_DUP_ENTRY
insert into t1 values(null) /* Not binlogged */;
# Insert with autogenerated key + duplicate key error should go into binlog
set insert_id=5;
insert ignore into t1 values(null) /* Insert 5 */;
select * from t1;
drop table t1;
# Same tests but with 2 rows inserted at a time
create table t1 (id tinyint auto_increment primary key) engine=myisam;
set insert_id=128;
--error HA_ERR_AUTOINC_ERANGE
insert into t1 values(5),(null) /* Insert_id 128 */;
# The followin insert ignore will be put in binlog
set insert_id=128;
insert ignore into t1 values (4),(null) /* Insert_id 128 */;
# Insert with duplicate key error should not go into binglo
set insert_id=5;
--error ER_DUP_ENTRY
insert into t1 values(3),(null) /* Insert_id 5 */;
# Insert with autogenerated key + duplicate key error should go into binlog
set insert_id=5;
insert ignore into t1 values(2),(null) /* Insert_id 5 */;
select * from t1 order by id;
drop table t1;
# bug#22027
create table t1 (a int);
create table if not exists t2 select * from t1;
# bug#22762
select @@binlog_format;
create temporary table tt1 (a int);
create table if not exists t3 like tt1;
# BUG#25091 (A DELETE statement to mysql database is not logged with
# ROW mode format): Checking that some basic operations on tables in
# the mysql database is replicated even when the current database is
# 'mysql'.
USE mysql;
INSERT db SET host='localhost', user='@#@', db='Just a test';
UPDATE db SET db='Another db' WHERE host='localhost' AND user='@#@';
DELETE FROM db WHERE host='localhost' AND user='@#@';
use test;
source include/show_binlog_events.inc;
drop table t1,t2,t3,tt1;
-- source suite/binlog/include/binlog_insert_delayed.test
#Bug #26079 max_binlog_size + innodb = not make new binlog and hang server
# server should not hang, binlog must rotate in the end
reset master;
--disable_warnings
drop table if exists t3;
--enable_warnings
create table t3 (a int(11) NOT NULL AUTO_INCREMENT, b text, PRIMARY KEY (a) ) engine=innodb;
--let $binlog_file1= query_get_value(SHOW MASTER STATUS, File, 1)
--echo File $binlog_file1
let $it=4;
while ($it)
{
insert into t3(b) values ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
dec $it;
}
--let $binlog_file2= query_get_value(SHOW MASTER STATUS, File, 1)
--echo *** show new binlog index after rotating ***
--echo File $binlog_file2
drop table t3;
--echo #
--echo # Bug #45998: database crashes when running "create as select"
--echo #
CREATE DATABASE test1;
USE test1;
DROP DATABASE test1;
CREATE TABLE test.t1(a int);
INSERT INTO test.t1 VALUES (1), (2);
CREATE TABLE test.t2 SELECT * FROM test.t1;
USE test;
DROP TABLES t1, t2;
#
# Bug#46640
# This test verifies if the server_id stored in the "format
# description BINLOG statement" will override the server_id
# of the server executing the statements.
#
connect (fresh,localhost,root,,test);
connection fresh;
RESET MASTER;
CREATE TABLE t1 (a INT PRIMARY KEY);
# Format description event, with server_id = 10;
BINLOG '
3u9kSA8KAAAAZgAAAGoAAAABAAQANS4xLjM1LW1hcmlhLWJldGExLWRlYnVnLWxvZwAAAAAAAAAA
AAAAAAAAAAAAAAAAAADe72RIEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
';
# What server_id is logged for a statement? Should be our own, not the
# one from the format description event.
INSERT INTO t1 VALUES (1);
# INSERT INTO t1 VALUES (2), with server_id=20. Check that this is logged
# with our own server id, not the 20 from the BINLOG statement.
BINLOG '
3u9kSBMUAAAAKQAAAJEBAAAAABoAAAAAAAAABHRlc3QAAnQxAAEDAAA=
3u9kSBcUAAAAIgAAALMBAAAQABoAAAAAAAEAAf/+AgAAAA==
';
# Show binlog events to check that server ids are correct.
--replace_column 1 # 2 # 5 #
--replace_regex /Server ver: .*, Binlog ver: .*/Server ver: #, Binlog ver: #/ /table_id: [0-9]+/table_id: #/
SHOW BINLOG EVENTS;
DROP TABLE t1;
--echo
--echo # BUG#54903 BINLOG statement toggles session variables
--echo # ----------------------------------------------------------------------
--echo # This test verify that BINLOG statement doesn't change current session's
--echo # variables foreign_key_checks and unique_checks.
--echo
CREATE TABLE t1 (c1 INT KEY);
SET @@SESSION.foreign_key_checks= ON;
SET @@SESSION.unique_checks= ON;
--echo # INSERT INTO t1 VALUES (1)
--echo # foreign_key_checks=0 and unique_checks=0
BINLOG '
dfLtTBMBAAAAKQAAANcAAAAAABcAAAAAAAEABHRlc3QAAnQxAAEDAAE=
dfLtTBcBAAAAIgAAAPkAAAAAABcAAAAAAAcAAf/+AQAAAA==
';
SELECT * FROM t1;
--echo # Their values should be ON
SHOW SESSION VARIABLES LIKE "foreign_key_checks";
SHOW SESSION VARIABLES LIKE "unique_checks";
--echo
SET @@SESSION.foreign_key_checks= OFF;
SET @@SESSION.unique_checks= OFF;
--echo # INSERT INTO t1 VALUES(2)
--echo # foreign_key_checks=1 and unique_checks=1
BINLOG '
dfLtTBMBAAAAKQAAAKsBAAAAABcAAAAAAAEABHRlc3QAAnQxAAEDAAE=
dfLtTBcBAAAAIgAAAM0BAAAAABcAAAAAAAEAAf/+AgAAAA==
';
SELECT * FROM t1;
--echo # Their values should be OFF
SHOW SESSION VARIABLES LIKE "foreign_key_checks";
SHOW SESSION VARIABLES LIKE "unique_checks";
--echo # INSERT INTO t1 VALUES(2)
--echo # foreign_key_checks=1 and unique_checks=1
--echo # It should not change current session's variables, even error happens
call mtr.add_suppression("BINLOG_BASE64_EVENT.*Could not execute Write_rows_v1 event on table test.t1; Duplicate entry .2. for key .PRIMARY., Error_code: 1062");
--error 1062
BINLOG '
dfLtTBMBAAAAKQAAAKsBAAAAABcAAAAAAAEABHRlc3QAAnQxAAEDAAE=
dfLtTBcBAAAAIgAAAM0BAAAAABcAAAAAAAEAAf/+AgAAAA==
';
SELECT * FROM t1;
--echo # Their values should be OFF
SHOW SESSION VARIABLES LIKE "foreign_key_checks";
SHOW SESSION VARIABLES LIKE "unique_checks";
DROP TABLE t1;
disconnect fresh;
connection default;
--echo #
--echo # MDEV-25595 DROP part of failed CREATE OR REPLACE is not written into binary log
--echo #
reset master;
--error ER_DUP_FIELDNAME
create table t as select 1 as b, 2 as b;
create table t (old_table_field int);
--error ER_DUP_FIELDNAME
create or replace table t as select 1 as b, 2 as b;
--error ER_DUP_FIELDNAME
create or replace temporary table t as select 1 as b, 2 as b;
create or replace temporary table t as select 1 as temp;
--error ER_DUP_FIELDNAME
create or replace temporary table t as select 1 as b, 2 as b;
--error ER_BAD_TABLE_ERROR
drop temporary table t;
--error ER_TABLE_EXISTS_ERROR
create table t (new_table_field int);
create or replace table t (new_table_field int);
--source include/show_binlog_events.inc
# cleanup
drop table t;
Reference in a new issue View git blame Copy permalink