Tungsten Replicator Beta-3 Is Available

Our fiendish plot to provide advanced open source replication for MySQL and Oracle took another step forward yesterday. The Tungsten Replicator beta-3 build is available for download on our Forge site. This build is fully open source. Tungsten Replicator provides heterogeneous replication from MySQL to Oracle, seamless failover from a master to one of several slaves, event checksums, event filtering hooks, and a number of other useful replication features for MySQL and Oracle previously not offered outside of commercial products.

The beta-3 build has a number of important improvements:

• MySQL 5.1 row replication is largely working. We are still seeing problems with datetime and timestamp replication but most other datatypes work.
  
• The state machine model used by the replicator has been upgraded substantially. State transitions are processed cleanly and a number of race conditions have been eliminated.
• You can now control master/slave failover remotely without any need to change local properties files. Planned failover passes our current tests, which means it's time to write new ones.
  
• Multiple replicators can read and write from the same database. This is a prerequisite for fan-in and circular replication.
  
• Numerous other bug fixes and small improvements are in the build.
  

For a full list of the build contents, read the Forge release notes or check the JIRA change log.

Our next build, beta-4, is scheduled for 5 January. It will tackle a number of key issues including corner cases for unplanned failure, scheduled table checksums, and heartbeat events. Plus we will continue to fix bugs and improve overall usability. Build contents are shown in the JIRA roadmap, a feature that delights the inner pointy-haired boss in all of us.

Please visit our community website and take the replicator out for a spin. It's improving quite rapidly. We take your feedback quite seriously--any reasonable request for capabilities will be considered and implemented if feasible.

In my next posts I will describe two key capabilities of Tungsten Replicator in more detail: replicating from MySQL to Oracle and filtering events. Stay tuned!

Don't Shy Away from MySQL 5.1!

MySQL 5.1 is GA. Let the fear and loathing begin. In a recent post Monty describes a number of problems that he feels should have prevented a GA declaration at this time. I like Monty's forthrightness immensely and his words have strongly influenced our work to develop the Tungsten Replicator. That said, I must respectfully disagree with his opinion.

It's hard to comment on overall quality of 5.1, though I have yet to hit any bugs personally after using it intermittently for almost a year. However, we have done a lot of work with MySQL row replication. Monty points out several bugs in the row replication implementation. Frankly, they would not hold me back. Row replication has so many advantages in eliminating strange corner cases from statement replication that it outweighs a few bugs. The MySQL 5.1 manual sums it up accurately:

Advantages of row-based replication:

• All changes can be replicated. This is the safest form of replication.

Beyond issues like provable correctness, row replication is simply more flexible than statement replication. Heterogeneous replication is an obvious example. Our own Tungsten Replicator can replicate statements from MySQL 5.0 to Oracle. That's great if you use completely vanilla SQL and stick to int and varchar datatypes. For real applications, however, you need a data structure that transfers datatypes accurate and is easy to morph across schema differences. Similar reasoning applies when using replication for application upgrades. Finally, row replication is the only viable path for implementing parallel slave update, which is increasingly necessary on multi-core hosts. I can't speak directly for Mats Kindahl and other members of the replication team, but there's no doubt they see row replication as the foundation to solve a number of key problems.

For these and other reasons our team at Continuent has devoted quite a bit of effort to reading row updates in MySQL 5.1 binlogs. Obviously, we have some uses in mind that go well beyond simple MySQL to MySQL data transfer. However, I would not shy away from MySQL 5.1 if I were using native replication. Instead, I would be testing row replication today to see what problems it solves for me. Congratulations to the MySQL team for getting this feature out the door.