Is synchronous replication possible in MySQL? Yes. Is it possible without major surgery to the existing code? Probably (or hopefully). Notes on an approach are at code.google.com.
The MySQL replication team may be working on this now for MySQL 6.0. They have spent a lot of time recently making replication flexible to support semi-sync and other new features. I assume they plan to support sync replication as well.
Posts
Kenny Gorman: Hello Shutterfly
1 hour ago
10 comments:
If you are willing and able to do replication above MySQL, then there are several options. I don't have experience with them. But some of them appear to be good. The usual issue with them is that all transactions must go through their framework and this may limit your client options (JDBC, Python, C++, ...). Eventually, a solution based on MySQL proxy might resolve that issue, but then you have to be willing to deploy (and depend on) Proxy and I am trying to reduce the complexity of my setup.
These solutions may also limit concurrent transactions on a server although the severity of the limit varies between products.
Hopefully, someone from Continuent will respond with details of their product.
Hi Mark!
Since you asked about Continuent, here's our take on this problem. Basically, you do [semi-]synchronous replication because you want strong guarantees against data loss. Here are four solutions:
1.) Middleware approaches like Sequoia and Dbshards force you to do through a framework. Middleware ordering algorithms are devilishly hard and limit your ability to handle more than a narrow range of applications.
2.) In-core models like what you describe here. This is the best approach in many ways but requires DBMS changes.
3.) Log mirroring using DRBD or similar technologies.
4.) Async replication with SQL routing through a library/proxy and notifications so that clients don't get a commit back until slave replicators acknowledge that they are up to date with the committed transaction.
Our philosophy for Tungsten is to integrate #2 where we find database support or go with #3 or #4. Tungsten will be announcing session consistency support shortly, which uses the same tricks necessary to implement #4.
Hi,
MySQL 6.0 development has ended, so the dev team would be working it on another version like 5.5.
Robert,
Can you describe session consistency?
We are not doing that much on synchronous replication at the moment. Some of the projects where we have lots of progress on now are:
1. Mixing transactional and non-transactional changes,
2. Multi-threaded slave
3. Transactional slave
4. Time-delayed slave
If someone wants to make a plugin for synchronous replication using the replication interface that was pushed to 6.0 (and that will be in 5.4), then that would be great. If the interface needs to be extended to support the plugin, then we are very interested in extending it too, so that plugins for synchronous replication will work.
Hi Mark!
Session consistency means that I as a user see my own writes but may look at old copies of data written by others. It's implemented by tracking the user sessions at the connection level. When you see the session write, you then direct all further connections on behalf of the user to the master until the slaves have caught up. The cool thing thing that your apps use a single connection and just pass in an option to indicate the user on behalf of whom they are acting.
At least that's how we do it. I'm just writing it up in a blog article that will appear shortly. Be interesting to know if your gang have done this.
Robert
Hi Lars,
We might be up for that as we have a kind of sick interest in this subject. :) When will the plug-in be available?
Cheers, Robert
Post a Comment