Changing an async slave of a PXC cluster to a new Master using 5.6 and GTID

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:

Share this post

Comments (2)

  • Alex Reply

    Hooray to that!

    Yet, doesn’t gtid_mode=on make server_id unnecessary?

    February 14, 2014 at 5:12 pm
  • Frederic Descamps Reply

    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.

    February 17, 2014 at 3:42 am

Leave a Reply