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."
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,
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.
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!
Add new comment