Replicating from MySQL to NuoDB Using Tungsten Replicator

You are here

Replicating from MySQL to NuoDB Using Tungsten Replicator

Error message

Note: This blog was published over a year ago. Content may be out of date.

Tungsten Replicator is a software package that allows replication to be established between MySQL and another database product. This blog post describes how to configure replication between MySQL and NuoDB.

The benefits of doing this are to:

1. Offload realtime analytics from an overloaded operational MySQL instance. Both NuoDB and MySQL would run side by side with NuoDB managing operational analytics.

2. Completely migrating an operational data store to NuoDB, to reap the benefits of elastic scalability without sharding, simple to manage redundancy, and built-in support for active-active geo-redundancy.

Here is how to configure replication from MySQL to NuoDB:

Step #1. Configure MySQL

MySQL must be configured to use row-based replication with no checksums. To achieve that, make sure /etc/my.cnf has the following entries:

and then restart MySQL. If you are running MySQL 5.6 , the loose-binlog-checksum and log-bin-use-v1-row-events options will make MySQL write the replication log in the 5.5 format that is compatible with Tungsten.

Step #4. Migrate the existing data

The following commands will export both the schema and the data from MySQL into NuoDB using the NuoDB Migrator tool – see http://dev.nuodb.com/techblog/2013/06/26/migrating-a-mysql-application-to-nuodb/. The migrator tool will create an equivalent schema to the source MySQL database in NuoDB and populate the NuoDB database with a copy of the data – essentially doing a one time synchronization of NuoDB with the base data in MySQL. We recommend doing this step when the source database is idle.

That is it, Tungsten will keep NuoDB synchronized as changes are made to the MySQL source database. You can check that any updates made on the MySQL server are propagated to the NuoDB database with your app or favorite SQL editing tool. These steps can also further be orchestrated to reduce/eliminate downtime.

What’s next?

This post gave a great overview of how to replicate a MySQL database. In an upcoming post we’ll focus on a migration using a active mysql instance and walk through the details around a live cutover with no downtime or data loss.

Our current solution currently doesn’t support DDL statement being issued on the MySQL side that contains MySQL-specific syntax. We’re also looking to add support for that.

We wish to thank our friends at Continuent for creating Tungsten, it is an excellent piece of infrastructure for managing the complexity of replication. It has been very easy to work with.