Before Percona XtraBackup 2.1.7 and Percona XtraDB Cluster 5.6.15-25.3, rsync was the only SST method supporting GTID in the way that it was possible to move an asynchronous slave from one Galera node to another one (related bug).
Indeed, previous versions of Percona XtraBackup didn’t copy any binary log and due to that, moving the async slave to another master, just broke replication (when writes still happened).
Now with the latest version of Percona XtraBackup and Percona XtraDB Cluster, wsrep_sst_xtrabackup-v2 handles the last binlog sent from Percona XtraBackup and allows the move to another master in the easiest ways as possible using CHANGE MASTER TO MASTER_HOST = "new node". Nothing else needed.
It’s also obvious that using 5.6 and GTID is easier than previous 5.5 where is was more tricky to point the slave to the right position (see Jay’s blog post).
Don’t forget to provide a server-id to your PXC nodes. This is an example of configuration settings needed in my.cnf to enable GTID on Galera/PXC nodes:
1 2 3 4 5 | server-id=2 log-bin=percona2-bin log_slave_updates enforce_gtid_consistency=1 gtid_mode=on |
Hooray to that!
Yet, doesn’t gtid_mode=on make server_id unnecessary?
Hi Alex,
During my test, if you don’t define a unique a server_id, the default value is 1 and then async replication (Slave_IO_Running) will stop with the following message :
And of course you should not start this option with “–log-slave-updates” it will even fail to avoid infinite loop.
So, for me, unique server_id is still necessary.