EmergencyEMERGENCY? Get 24/7 Help Now!

Migrating several single standalone MySQL server to one Percona XtraDB Cluster… MariaDB to the rescue !

 | December 18, 2012 |  Posted In: MySQL


Some weeks ago I had to migrate some independent MySQL servers (some standard MySQL masters, and some just standalone) to a Percona XtraDB Cluster of 3 nodes.

So the easiest way would be to configure each node to become also an asynchronous slave of one of the production servers.
Like illustrated here:

But in this case there was one major issue, the tables where MyISAM and this is not really recommended with Galera replication even if it’s now supported.

Preparing the slaves would then become a loop :

So in this case that should have be done 3 times… that could take some time ! And then, if the single production servers where more than 3 ?

So I decided to use a wonderful feature of MariaDB 10: Multi-source replication.

MariaDB’s multi-source-replication doesn’t have any conflict resolution. The assumption is that there are no conflicts in data between the different masters. Which is the case here, all standalone servers handle different schemas.

I configured the MariaDB server to be slave of all production servers, changed the table engine to InnoDB on it and chose one node of the PXC to be the async slave of that MariaDB server. It worked like a charm and the migration of production to Percona XtraDB Cluster became very easy.

Thank you MariaDB’s team for this feature.

When a sever (a node) is member of a Percona XtraDB Cluster is also standard slave (standard asynchronous replication of MySQL), it can spread in the cluster all statements received from the master if log_slave_updates is enabled.

Frederic Descamps

Frédéric joined Percona in June 2011, he is an experienced Open Source consultant with expertise in infrastructure projects as well in development tracks and database administration. Frédéric is a believer of devops culture.


  • In your pseudo code, perhaps you meant that you would do SST / get galera running and then for each node, import a .sql script and start standard MySQL replication from the respective hosts (If I understand correctly, the SST would just throw away local data and get a copy of the donor)

  • M,

    The problem here is that the tables were also MyISAM, so the plan would have been to restore one every node (or all dumps on the same node) and let do the SST to the other nodes and start the replication.

    In my example where I restore the dump on dedicated slave, so if we have node1, node2 and node3, that are respectively slaves of master1, master2 and master3, you first restore the dump1 (backup of master1) on node1, you alter the tables to InnoDB and then you start the other node one bye one with node1 as donor…. and then you do it again on node2, by stopping node1 and node3, … this is very long process…

Leave a Reply