[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: |
|
||||||||||||||||
| 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:
Test case:
bzr version-info
|
| 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. |