Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.2
-
Fix Version/s: 10.0.4
-
Component/s: None
-
Labels: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
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-26 Global transaction ID
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Fix pushed to 10.0-base.
Still reproducible with the new implementation, on 10.0-base revno 3635, both with current_pos and slave_pos.