Support GTID in XtraBackup

Registered by Alexey Kopytov on 2013-02-07

Include the value of gtid_executed (or its Executed_Gtid_Set equivalent from SHOW MASTER STATUS) into xtrabackup_binlog_info. The value (when available) is also printed by innobackupex along with the binary log position, e.g.:

innobackupex: MySQL binlog position: filename 'mysql-bin.000003', position 1781, gtid_executed bf9000c0-acc2-11e2-a411-ae6a09f09722:1-3

We should also update our docs accordingly and describe the GTID-based slave setup procedure as described in the whiteboard and the referenced MPB post.

Blueprint information

Status:
Complete
Approver:
Alexey Kopytov
Priority:
High
Drafter:
Miguel Angel Nieto
Direction:
Approved
Assignee:
Alexey Kopytov
Definition:
Approved
Series goal:
Accepted for 2.0
Implementation:
Implemented
Milestone target:
None
Started by
Alexey Kopytov on 2013-04-24
Completed by
Alexey Kopytov on 2013-04-25

Whiteboard

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

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.