Migrate from Galera to Tungsten Clustering without Downtime

One question we often get from potential customers is, “Tungsten Clustering meets all of our needs, but how do we migrate off our existing systems?” As part of our support, we help our new customers with these kinds of migrations. Although the process is similar for most sources, I’ll show you specifically how we migrate from Galera to Tungsten Cluster. The steps for this process are:

• Install Tungsten Cluster
• Take a backup of your existing source database
• Restore the backup into Tungsten Cluster
• Establish real-time replication from the source database to Tungsten Cluster
• Repoint apps

To accompany this blog, feel free to view the on-demand webinar, "How to Migrate from Galera to Tungsten Clustering."

The Backup

We will assume that we have a working Tungsten Cluster install. To prepare for the backup, we should add these lines into our MySQL configuration (sometimes named galera.cnf):

log-bin=galera-bin
log-slave-updates
server-id=1

We will need binary logging, which is often not enabled in Galera, for replication later. We also need log-slave-updates so each node in the Galera cluster logs transactions that originate from other nodes in a multi-master topology. Lastly, we need to set the MySQL server-id for the Tungsten Replicator to use (it doesn’t matter what it is set to, it just needs to be an integer and unique among database servers). After setting these parameters, do a rolling restart of the database nodes.

There are several options for taking a backup, so feel free to use your favorite method. The backup MUST contain the binlog position at the time of the backup. Xtrabackup and mariabackup do this automatically, and mysqldump will do it as long as --master-data=2 is specified. One thing about using xtrabackup: it is database specific -- you need to use the same version of the database on the source and targets. For example, if you are using Galera cluster from MariaDB version 10.1, you should use that same database version in your target cluster, otherwise you may not be able to start the database after it has been restored. mysqldump usually doesn’t have this limitation, and Tungsten allows you to mix MySQL versions anyway.

Restore the Backup

Now we need to restore the backup into the Tungsten Cluster. Keep in mind that we’ve not touched the Galera cluster and applications are still online. If you used mysqldump for the backup, it’s easy to restore into Tungsten - simply run tpm connector < dump.sql to restore it, and Tungsten replication will take care of the rest, replicating all of the changes throughout the cluster. Otherwise, put the cluster into maintenance mode and restore the backup created by xtrabackup (or snapshot) onto each node of the Tungsten Cluster. Then reset the Replicator on each node by running trepctl reset -all -y.

Establish Real-Time Replication using Tungsten Replicator

The quickest way to get Tungsten Replicator configured is to install it directly on one of the Galera nodes. Here’s a sample tungsten.ini configuration file:

[defaults]
user=tungsten
install-directory=/opt/continuent
disable-security-controls=true
start-and-report=false
[old2new]
replication-user=tungsten
replication-password=secret
replication-host=conn1
replication-port=3306
master=galera01
members=galera01
topology=direct

Note the following options: replication-host is set to a connector host in the Tungsten Cluster. Tungsten Replicator will then apply through a connector, thus providing high availability - if the primary fails or if there is a switch, the connector will make sure all of the write from the replicator will apply to the correct primary. replication-port is set to the port that the connector listens on (usually 3306). Finally, master and members are set to the Galera host that we are installed upon and extracting from.

Now we install Tungsten Replicator: tools/tpm install, and start it: replicator start offline (we do not want to bring the replicator online yet - we need to set the extraction position first). Now we can set the extraction position, based on the binary log position that we have either from xtrabackup or in the mysqldump file:

dsctl set -seqno 0 -epoch 0 -event-id "mysql-bin.000082:0000000014031577;-1" -source-id "galera01" -reset

Be sure to fill in the binary log position in the event-id argument, and the source Galera node in the source-id argument. Finally: trepctl online. Replication should start from the point where the backup left off, catch up, and in a little while the Tungsten cluster will be in sync with Galera, with replication flowing in real-time from Galera to Tungsten Clustering!

The Switch to Tungsten

At this point, your app servers are still pointing to Galera, and your Tungsten Cluster is in sync real time with Galera. Now it’s just a matter of stopping writes from your apps to Galera, verifying all of the writes have caught up in your Tungsten Cluster, and finally just point your apps to the Tungsten Cluster. You are now live on Tungsten Clustering! You can then stop the old2new replication stream.

Run the command: trepctl status to verify that the replicator latency is low which shows that it is all caught up.

Conclusion

Migrating to Tungsten Clustering with no downtime is an easy process, and migrating from other sources works in the same way as from Galera. The key thing to keep in mind when migrating from Galera is to enable binary logging, and then use our standard migration process. Feel free to view my on-demand webinar, "How to Migrate from Galera to Tungsten Clustering," or submit a webform to get help from our team!