David Shrewsbury: Drizzle Replication Progress Report
In an attempt to keep folks up-to-date as to what is happening with Drizzle replication, I thought that I'd blog about what we are currently doing, and where we are heading.Current Area of Focus
A building is only as solid as its foundation. For Drizzle replication, that foundation is the transaction log. Our focus, as of late, has been testing the transaction log heavily, ensuring that the messages within it are correct and that its contents can be successfully used to replicate to another machine and have an exact copy of our data. Myself, Patrick Crews (awesome QA guy), and Joe Daly (awesome contributor) have been focused on this testing and fixing bugs for the last several weeks. This Launchpad Blueprint tracks our progress an! d list of bugs. And Patrick has posted some blog entries about this work.
Initially we started out simple with a single database session. This helped to uncover many issues, most of which have been fixed. We have now moved on to testing our transaction log with many concurrent database connections. The results are looking very good so far!
Next Steps
In its simplest form, replication can be achieved by just shipping the transaction log file from master to slave and applying it to the slave. Drizzle obviously needs a solution for this since we do not yet have a native implementation of replication. So we've decided that as a first-phase replication solution, we'll use a 3rd party solution to help us.
I looked at a few options at how we could impl! ement this:
- RabbitMQ - This is a message exchange system that would allow us to simply send our Google Protobuf Messages (the basic unit of communication in our replication architecture) from the master's transaction log (or alternatively, as a plugin reading the replication stream directly from the Drizzle kernel) to a server running RabbitMQ. Slaves could then connect to the RabbitMQ server to receive the replication events. This has the benefit of moving much of the I/O associated with replication off to another machine. Also, we already have a plugin created by Marcus Eriksson that will send the replication events to a RabbitMQ server. He also has an applier that will run on the slave to receive the events and apply them to the database.
- ZeroMQ - So! meone suggested that I look at this. This is an asynchronous message-processing library that looks really interesting. However, this is a networking library and would be more appropriate to use this in a native replication solution, which is a possibility in the future.
- Tungsten Replicator - Continuent supplies an open source solution for replication for multiple database platforms (notably MySQL and Postgres). It provides some wonderful features, like easy promotion of slave to master in case of failure, and filtering of transaction log events.
ZeroMQ doesn't really fit what I was looking for in this phase (to write as little code as possible), so I've put off looking at it for now. Though I am excited to look at using this in the future.
RabbitMQ was a good possibility. Marcus has already done quite a bit of work with this, but the code is a bit out of da!
te currently. There have been several changes to the protobuf messages
since Marcus originally wrote this code, and it's difficult to keep up when we change so quickly. Still, it wouldn't take much effort to get this code up-to-date and working.
Honestly, I didn't know much about Tungsten Replicator until recently. This really looks like an excellent, full-featured product. It is well thought out in its design, and seems to be fairly simple to get up and running. Then I got really excited about it when I found out that Marcus has already been working with Continuent on adding Drizzle support! Not only that, Marcus announced his creation of a set of Java tools that contain the common code for working with the Drizzle transaction log. This can be used in his Tungsten work, as well as re-incorporated into his RabbitMQ work eventually.
It seems like a real w!
in to work with Marcus on helping him to add Drizzle support to Tungsten, so this, along with transaction log testing, is my focus going forward. I hope to write up a simple HOWTO on using Tungsten Replicator with Drizzle once it is ready to use.
Looking to the Future
While nothing is written in stone just yet, we have multiple potential ideas for replication that are pretty exciting. Just some of them are:
- Replication streams separated on a per-catalog basis. This would help to eliminate some contention issues and reduce the headaches that a single user could cause to the entire replication system.
- Ability to limit resource usage of the slave, such as limiting concurrent writes per device.
- Optional compression of the replication stream.
Although we have a bit of work to do, I think we have the potential to deliver some pretty in!
teresting stuff in the future.
What o
ther ideas would you like to see implemented in Drizzle replication?
URL: http://dshrewsbury.blogspot.com/2010/10/drizzle-replication-progress-report.html
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
