Bug #88296 Multi-source + GTID operational limitations

• Submitted: 30 Oct 2017 14:07
• Reporter: Marcos Albe (OCA)
• Status: Open
• Category: MySQL Server: Replication
• Severity: S4 (Feature request)
• Version: 5.7
• OS: Any
• CPU Architecture: Any

[30 Oct 2017 14:07] Marcos Albe

Description:
Given two servers M1 and M2, and server S1 if we want to setup:

M1 <--- GTID --- S1 (channel1)
M2 <--- GTID --- S1 (channel2)

The only way to do it is to setup both channels at the same time;  Setting up one channel first and the other later will force a RESET MASTER that causes operational complexities as the binlog entries in S1 produced through channel1 would be truncated at the point we RESET MASTER to set GTID_PURGED to start next channel.  So if we had a slave S2 that replicates from S1, one would always need to be on the look for that before doing RESET MASTER.

Also documentation here https://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-multi-source-adding... is not clear on steps to setup, and states CHANGE MASTER... AUTO_POSITION=1 is enough and never mentions you should set GTID_PURGED.  

Also would be nice to state that setting GTID sequences from both masters in GTID_PURGED at the same time is how you can get this working.

How to repeat:
Setup multi-source replication using gtid, one channel at a time. Observe how binlogs in the slave produced by replication of events in the channel that was setup first, disappear.

Suggested fix:
Prevent the binlogs from disappearing.

Not sure...RESET GTID_PURGED?  RESET MASTER NO_TRUNCATE_BINLOGS?  SET GTID_PURGED FOR CHANNEL x?  CHANGE MASTER .... GTID_PURGED=x?