5.11.2. Migrating from MySQL Native Replication Using a New Service
When running an existing MySQL native replication service that needs to be
migrated to a Tungsten Clustering service, one solution is to create the new
Tungsten Clustering service, synchronize the content, and then install a
service that migrates data from the existing native service to the new
service while applications are reconfigured to use the new service. The
two can then be executed in parallel until applications have been
The basic structure is shown in
Figure 5.2, “Migration: Migrating Native Replication using a New Service”. The
migration consists of two steps:
Once the application has been switched and is executing against the new
service, the secondary replication can be disabled by shutting down the
Tungsten Replicator in
Figure 5.2. Migration: Migrating Native Replication using a New Service
To configure the service:
Stop replication on a slave for the existing native replication
Obtain the current slave position within the master binary log :
SHOW SLAVE STATUS\G
Create a backup using any method that provides a consistent snapshot.
The MySQL master may be used if you do not have a slave to backup
from. Be sure to get the binary log position as part of your back.
This is included in the output to Xtrabackup or
option with mysqldump.
Restart the slave using native replication :
On the master and each slave within the new service, restore the
backup data and start the database service
Setup the new Tungsten Clustering deployment using the MySQL servers on
which the data has been restored. For clarity, this will be called
Configure a second replication service,
beta to apply data using the
existing MySQL native replication server as the master, and the master
For more information, see
Section 3.5, “Replicating Data Into an Existing Dataservice”.
Do not start the new service.
Set the replication position for
tungsten_set_position to set the position to the
point within the binary logs where the backup was taken:
--seqno=0 --epoch=0 --service=
Start replicator service
Once replication has been started, use trepctl to check
the status and ensure that replication is operating correctly.
The original native MySQL replication master can continue to be used for
reading and writing from within your application, and changes will be
replicated into the new service on the new hardware. Once the applications
have been updated to use the new service, the old servers can be
decommissioned and replicator service
beta stopped and removed.