On a cluster that has GTID slaves, make-co-master appears uses binlog positioning

[leeparayno]

On a cluster with GTID slaves, where one of the slaves is used in a call to make-co-master, the master is made a slave of the specified slave instance using binlog positioning rather than GTID.

In the older GTID migration steps for MySQL 5.6, we can be sure that GTID has been enabled on all instances in the cluster.

It would appear to me to be optimal for the master to be made a GTID slave of the specified slave rather than using binlog positioning. Perhaps checking whether GTID_MODE is ON or the newer permissive variations from 5.7, and opting for a CHANGE MASTER command using MASTER_AUTO_POSITION = 1 instead.

[shlomi-noach]

Thank you. Yes, the make-co-master doesn't fall under the "smart" operations, and doesn't try to auto-deduce the best course of action. Having said that, and because you're using GTID, the fact that it attempts to use binlog:position is meaning less. GTID would sort it out anyhow. Do you see any harm done in your case?