Support GTID in XtraBackup

If we are taking a backup from a master/slave server using GTID we don't need binary log and position to set up the replication (but we need it to PITR). Instead, we need to store the global variable value of "gtid_executed".

I think that this should be an automatic feature. If innobackupex checks that gtid_mode=ON on my.cnf, then store the value of gtid_executed on a file like we do with binary log and position. Of course, the value we get from gtid_executed needs to be consistent with the backup. During the backup, the file auto.cnf from datadir should be excluded, because it contains the server UUID and it should be different between master and slaves.

Then on the slave, we need to restore the backup and instead of using the binary log information we need to use the gtid_executed information.

Create new slave:

1- restore the backup on the slave
2- read the value of gtid_executed from the file xtrabackup_gtid_executed
3- slave1> SET GLOBAL gtid_purged='xxxxx';
4- slave1> CHANGE MASTER TO MASTER_HOST.... blahblah, MASTER_AUTO_POSITION = 1;
5- slave1> start slave;

Restore a failed slave:

1- restore the backup on the slave
2- read the value of gtid_executed from the file xtrabackup_gtid_executed
3- slave1> reset master;
3- slave1> SET GLOBAL gtid_purged='xxxxx';
4- slave1> CHANGE MASTER TO MASTER_HOST.... blahblah, MASTER_AUTO_POSITION = 1;
5- slave1> start slave;

http://www.mysqlperformanceblog.com/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/

That's all.

-- Miguel Angel

Note that you don't need binlog file and position for PITR recovery. For PITR recovery if you have the GTID set you want to stop at, you can do START SLAVE UNTIL SQL_BEFORE_GTIDS (or START SLAVE UNTIL SQL_AFTER_GTIDS).

-- Sheeri Cabral