Description:
When setting up a GTID-based replication chain you tend to start with the gtid_executed comprising of a single UUID (from the master) plus the transaction sequences from that server. That's fine.
However, we we replace the master with a new one we add a new UUID plus transaction sequences to the GTID set so now we have 2 values.
If this process happens a lot you can end up with quite a lot of values in GTID_EXECUTED or GTID_PURGED and many UUID ranges will be for servers which no longer exist or will exist in the future. It's useless data.
Removing this data at the moment is not possible on a live system as you can't stop the master, wipe out the binary logs and start again, as you go offline and all slaves would break if you did this.
How to repeat:
Move servers around (changing the master) and see that you get this sort of situation.
Suggested fix:
Provide a mechanism so that old GTID values (probably based by UUID) can be forgotten by triggering an action on the master to make it forget about the old UUID(s).
* This process should "replicate" the change to any downstream slaves so that they all see a common vision of the "state of the database"
* Some safety checks should be made to ensure that no slave connected to the master is receiving data from such a UUID (e.g. a delayed slave) as that would trigger replication to break.
