mariadb/mysql-test/suite/binlog/include/binlog.test
Monty f8ba5ced55 MDEV-36099 Ensure that creation and usage of temporary tables in replication is predictable
MDEV-36563 Assertion `!mysql_bin_log.is_open()' failed in
           THD::mark_tmp_table_as_free_for_reuse

The purpose of this commit is to ensure that creation and changes of
temporary tables are properly and predicable logged to the binary
log.  It also fixes some bugs where ROW logging was used in MIXED mode,
when STATEMENT would be a better (and expected) choice.

In this comment STATEMENT stands for logging to binary log in
STATEMENT format, MIXED stands for MIXED binlog format and ROW for ROW
binlog format.

New rules for logging of temporary tables
- CREATE of temporary tables are now by default binlogged only if
  STATEMENT binlog format is used. If it is binlogged, 1 is stored in
  TABLE_SHARE->table_creation_was_logged. The user can change this
  behavior by setting create_temporary_table_binlog_formats to
  MIXED,STATEMENT in which case the create is logged in statement
  format also in MIXED mode (as before).
- Changes to temporary tables are only binlogged if and only if
  the CREATE was logged. The logging happens under STATEMENT or MIXED.
  If binlog_format=ROW, temporary table changes are not binlogged. A
  temporary table that are changed under ROW are marked as 'not up to
  date in binlog' and no future row changes are logged.  Any usage of
  this temporary table will force row logging of other tables in any
  future statements using the temporary table to be row logged.
- DROP TEMPORARY is binlogged only of the CREATE was binlogged.

Changes done:
- Row logging is forced for any statement using temporary tables that
  are not up to date in the binary log.
  (Before the row logging was forced if the user has a temporary table)
- If there is any changes to the temporary table that is not binlogged,
  the table is marked as not up to date.
- TABLE_SHARE->table_creation_was_logged has a new definition for
  temporary tables:
  0  Table creating was not logged to binary log
  1  Table creating was logged to binary log and table is up to date.
  2  Table creating was logged to binary log but some changes where
     not logged to binary log.
  Table is not up to date in binary log is defined as value 0 or 2.
- If a multi-table-update or multi-table-delete fails then
  all updated temporary tables are marked as not up to date.
- Enforce row logging if the query is using temporary tables
  that are not up to date.
  Before row logging was enforced if the user had any
  temporary tables.
- When dropping temporary tables use IF EXISTS. This ensures
  that slave will not stop if it had crashed and lost the
  temporary tables.
- Remove comment and version from DROP /*!4000 TEMPORARY.. generated when
  a connection closes that has open temporary tables. Added 'generated by
  server' at the end of the DROP.

Bugs fixed:
- When using temporary tables with commands that forced row based,
  like INSERT INTO temporary_table VALUES (UUID()), this was never
  logged which causes the temporary table to be inconsistent on
  master and slave.
- Used binlog format is now clearly defined. It is now only depending
  on the current binlog_format and the tables used.
  Before it was depending on the user had ANY temporary tables and
  the state of 'current_stmt_binlog_format' set by previous queries.
  This also caused temporary tables to be logged to binary log in
  some cases.
- CREATE TABLE t1 LIKE not_logged_temporary_table caused replication
  to stop.
- Rename of not binlogged temporary tables where binlogged to binary log
  which caused replication to stop.

Changes in behavior:

- By default create_temporary_table_binlog_formats=STATEMENT, which
  means that CREATE TEMPORARY is not logged to binary log under MIXED
  binary logging. This can be changed by setting
  create_temporary_table_binlog_formats to MIXED,STATEMENT.
- Using temporary tables that was not logged to the binary log will
  cause any query using them for updating other tables to be logged in
  ROW format. Before all queries was logged in ROW format if the user had
  any temporary tables, even if they were not used by the query.
- Generated DROP TEMPORARY TABLE is now always using IF EXISTS and
  has a "generated by server" comment in the binary log.

The consequences of the above is that manipulations of a lot of rows
through temporary tables will by default be be slower in mixed mode.

For example:
  BEGIN;
  CREATE TEMPORARY TABLE tmp AS SELECT a, b, c FROM
  large_table1 JOIN large_table2 ON ...;
  INSERT INTO other_table SELECT b, c FROM tmp WHERE a <100;
  DROP TEMPORARY TABLE tmp;
  COMMIT;

By default this will create a huge entry in the binary log, compared
to just a few hundred bytes in statement mode. However the change in
this commit will make usage of temporary tables more reliable and
predicable and is thus worth it. Using statement mode or
create_temporary_table_binlog_formats can be used to avoid this issue.
2025-04-28 12:59:38 +03:00

428 lines
12 KiB
Text

#
# 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 table t (new_table_field int);
--source include/show_binlog_events.inc
# cleanup
drop table t;