5.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 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 migrated.

The basic structure is shown in Figure 5.2, “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 5.2. Migration: Migrating Native Replication using a New Service

Migration: Migrating Native Replication using a New Service

To configure the service:

  1. Stop replication on a slave for the existing native replication installation :

    mysql> STOP SLAVE;

    Obtain the current slave position within the master binary log :

                      Master_Host: host3
                  Master_Log_File: mysql-bin.000002
              Exec_Master_Log_Pos: 559
  2. 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 using the --master-data=2 option with mysqldump.

  3. Restart the slave using native replication :

    mysql> START SLAVE;
  4. On the master and each slave within the new service, restore the backup data and start the database service

  5. Setup the new Tungsten Clustering deployment using the MySQL servers on which the data has been restored. For clarity, this will be called newalpha.

  6. Configure a second replication service, beta to apply data using the existing MySQL native replication server as the master, and the master of newalpha.

    For more information, see Section 3.6, “Replicating Data Into an Existing Dataservice”.

    Do not start the new service.

  7. Set the replication position for beta using tungsten_set_position to set the position to the point within the binary logs where the backup was taken:

    shell> /opt/replicator/tungsten/tungsten-replicator/bin/tungsten_set_position \
        --seqno=0 --epoch=0 --service=beta \
        --source-id=host3 --event-id=mysql-bin.000002:559
  8. 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 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.