Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.2
-
None
-
None
Description
Possibly it currently works by design, and then it's more of a feature request than a bug report
As soon as we execute CHANGE MASTER TO MASTER_USE_GTID = 1 on a slave which had some master position, the master coordinates get reset.
It's understandably that the slave does not use old coordinates if it's configured to use GTID instead, but it seems dangerous to forget them before it even connected to the master and received the new (GTID-based position). For example, a user could issue the CHANGE by mistake, and immediately, before starting the slave, set MASTER_USE_GTID back to 0; but the position is already lost, and further attempt to start slave will cause data inconsistency and replication failure. Or, it might happen that the master does not support GTID, so the slave won't start. It produces very comprehensive error message, but it's quite difficult to fix the problem because the previous position is already forgotten.
Test case:
--source include/master-slave.inc
|
|
CREATE TABLE t1 (i int); |
|
--sync_slave_with_master
|
|
--source include/stop_slave.inc
|
CHANGE MASTER TO MASTER_USE_GTID = 1; |
CHANGE MASTER TO MASTER_USE_GTID = 0; |
--source include/start_slave.inc
|
|
--connection master
|
INSERT INTO t1 VALUES (1); |
--sync_slave_with_master
|
|
fails with
Last_Error Error 'Table 't1' already exists' on query. Default database: 'test'. Query: 'CREATE TABLE t1 (i int)'
|
bzr version-info
revision-id: knielsen@knielsen-hq.org-20130503092729-gedp152b19k5wdnj
|
revno: 3626
|
branch-nick: 10.0-base
|
Attachments
Issue Links
- relates to
-
MDEV-26 Global transaction ID
- Closed