6.12.2. Migrating from MySQL Native Replication Using a New Service

6.12.2. Migrating from MySQL Native Replication Using a New Service
Prev	^Up	6.12. Migrating and Seeding Data	Next

6.12.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 Cluster service, one solution is to create the new Tungsten Cluster 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 migrated.

The basic structure is shown in Figure 6.1, “Migration: Migrating Native Replication using a New Service”. The migration consists of two steps:

Initializing the new service with the current database state.
Creating a Tungsten Replicator deployment that continues to replicate data from the native MySQL service to the new service.

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 /opt/replicator.

Figure 6.1. Migration: Migrating Native Replication using a New Service

To configure the service:

Stop replication on a Replica for the existing native replication installation :

mysql> STOP SLAVE;

Obtain the current Replica position within the Primary binary log :

mysql> SHOW SLAVE STATUS\G
...
                  Master_Host: host3
              Master_Log_File: mysql-bin.000002
          Exec_Master_Log_Pos: 559
...

Create a backup using any method that provides a consistent snapshot. The MySQL Primary may be used if you do not have a Replica 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 using the --master-data=2 option with mysqldump.
Restart the Replica using native replication :
```
mysql> START SLAVE;
```
On the Primary and each Replica within the new service, restore the backup data and start the database service
Setup the new Tungsten Cluster deployment using the MySQL servers on which the data has been restored. For clarity, this will be called newalpha.
Configure a second replication service, beta to apply data using the existing MySQL native replication server as the Primary, and the Primary of newalpha.
For more information, see Section 3.8, “Replicating Data Into an Existing Dataservice”.
Do not start the new service.

Set the replication position for beta using the dsctl set command to set the position to the point within the binary logs where the backup was taken:

shell> /opt/replicator/tungsten/tungsten-replicator/bin/dsctl -service beta set -reset \
    -seqno 0 -epoch 0 \
    -source-id host3 -event-id mysql-bin.000002:559

Start replicator service beta:

shell> /opt/replicator/tungsten/tungsten-replicator/bin/replicator start

Once replication has been started, use trepctl to check the status and ensure that replication is operating correctly.

The original native MySQL replication Primary 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.

Prev	Up	Next
6.12.1. Migrating from MySQL Native Replication 'In-Place'	^Level	6.13. Resetting a Tungsten Cluster Dataservice

Continuent Documentation

6.12.2. Migrating from MySQL Native Replication Using a New Service