Description:
The global transaction id and simplifying the way to keep track of the replication position and avoid repeating transactions is great. One of the issues I see with the required configuration in order to enable this is according to: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html to enable this functionality:
--log-bin --log-slave-updates
From what I can see this is to ensure that a record of all "transactions" are stored in the binlogs, so that when you start up you know the already seen transaction ids (per server uuid) and this prevents any transaction being re-executed.
That's great. Of course that means that all slaves must be configured this way. You also want a slave to be able to not repeat a transaction that has been processed but the implication of the configuration settings above are that you _force_ the slave server to write binlogs (probably sync them), and thus maintain disk space for those written files.
In many environments the slave is NEVER expected to be promoted to a master so there is no need to enable binlogging. This is done to save disk space, but also to save I/O. This new setup, if we were to use GTID functionality, would require people to look carefully at existing environments to see if the extra disk space and I/O requirements would be an issue, something that I think in many cases might be the case.
How to repeat:
Read the manual, and setup GTID as explained here: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-restrictions.html.
Check the affect of extra disk space requirements or extra I/O triggered by this change.
A normal downstream master (which often happens) would not be affected by this, nor would a slave that was previously configured to be a failover master as it would already have binlogs enabled.
Slaves which are not intended to be failover masters would have extra resource requirements.
Suggested fix:
The GTID idea is good. Storing the GTID information seen so far: the set of server-uuid, min, max sequence numbers, is fine, but for a box which only needs to know how to syncronise back to it's master or another master which is also replicating from the same server there's no need to know anything but these id, sequence number values. Storing all the binlogs is just a waste of resources.
Please consider a way to configure MySQL so that just the needed GTID information can be saved, thus reducing the extra resource issues, and avoid having to write to binlogs with all the replicated statements or rowbased image changes.
