[MDEV-4596] CREATE TABLE .. AS SELECT .. executed with RBR causes discrepancy in GTID sequence Created: 2013-05-28  Updated: 2014-02-25  Resolved: 2014-02-25

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: 10.0.8

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
blocks MDEV-4934 A group of events under single GTID c... Closed
Relates
relates to MDEV-26 Global transaction ID Closed

 Description   

With RBR, statements like CREATE TABLE .. AS SELECT .. are written into the binary log in two parts: the CREATE part is in the statement format, as any DDL, and the INSERT part in the row format. When it's written on the server that executed it, both parts share the same GTID. But when it's applied on the slave, each part gets its own GTID. Thus, it causes a discrepancy between master and slave GTID sequences, and between binlog_pos and slave_pos.

Test output:

include/master-slave.inc
[connection master]
ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB;
CREATE TABLE t1 AS SELECT 1;
SHOW BINLOG EVENTS;
Log_name	Pos	Event_type	Server_id	End_log_pos	Info
master-bin.000001	4	Format_desc	1	248	Server ver: 10.0.1-MariaDB-gcov-debug-log, Binlog ver: 4
master-bin.000001	248	Gtid_list	1	273	[]
master-bin.000001	273	Binlog_checkpoint	1	313	master-bin.000001
master-bin.000001	313	Gtid	1	351	GTID 0-1-1
master-bin.000001	351	Query	1	460	use `test`; ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB
master-bin.000001	460	Gtid	1	498	BEGIN GTID 0-1-2
master-bin.000001	498	Query	1	616	use `test`; CREATE TABLE `t1` (
  `1` int(1) NOT NULL DEFAULT '0'
)
master-bin.000001	616	Table_map	1	657	table_id: 45 (test.t1)
master-bin.000001	657	Write_rows	1	691	table_id: 45 flags: STMT_END_F
master-bin.000001	691	Query	1	760	COMMIT
SHOW BINLOG EVENTS;
Log_name	Pos	Event_type	Server_id	End_log_pos	Info
slave-bin.000001	4	Format_desc	2	248	Server ver: 10.0.1-MariaDB-gcov-debug-log, Binlog ver: 4
slave-bin.000001	248	Gtid_list	2	273	[]
slave-bin.000001	273	Binlog_checkpoint	2	312	slave-bin.000001
slave-bin.000001	312	Gtid	1	350	GTID 0-1-1
slave-bin.000001	350	Query	1	459	use `test`; ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB
slave-bin.000001	459	Gtid	1	497	GTID 0-1-2
slave-bin.000001	497	Query	1	615	use `test`; CREATE TABLE `t1` (
  `1` int(1) NOT NULL DEFAULT '0'
)
slave-bin.000001	615	Gtid	1	653	BEGIN GTID 0-1-3
slave-bin.000001	653	Table_map	1	694	table_id: 46 (test.t1)
slave-bin.000001	694	Write_rows	1	728	table_id: 46 flags: STMT_END_F
slave-bin.000001	728	Query	1	788	COMMIT
SHOW VARIABLES LIKE 'gtid%';
Variable_name	Value
gtid_binlog_pos	0-1-3
gtid_current_pos	0-1-2
gtid_domain_id	0
gtid_seq_no	0
gtid_slave_pos	0-1-2
gtid_strict_mode	OFF

Test case:

--source include/master-slave.inc
--source include/have_innodb.inc
--source include/have_binlog_format_row.inc
 
ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB;
CREATE TABLE t1 AS SELECT 1;
SHOW BINLOG EVENTS;
 
--sync_slave_with_master
SHOW BINLOG EVENTS;
SHOW VARIABLES LIKE 'gtid%';

bzr version-info

revision-id: knielsen@knielsen-hq.org-20130528112831-vwbv19062dipob0b
revno: 3636
branch-nick: 10.0-base



 Comments   
Comment by Elena Stepanova [ 2013-06-23 ]

Modified the type of the links to other issues, 'blocked by' was set by mistake.

Comment by Kristian Nielsen [ 2013-08-27 ]

Hm, this is actually fairly serious I think, it creates discrepancy between gtid sequence on master and slave.

It looks a bit tricky to fix. I think the proper way is to log the create and the row events as separate events on the master. The problem is that this logging must be done only at the end of the statement (as it should not happen in case of failure and rollback), so we need to hold onto two transactions and thus two gtids somehow. I'll try to find someone to discuss how to do this with and re-visit it again later.

I noticed that in MySQL 5.6 GTID, they simply decided that create...select is "not supported". I do not like that solution...

Comment by Kristian Nielsen [ 2014-01-08 ]

Monty promised to fix this.

Generated at Thu Feb 08 06:57:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.