I'm looking at the schedule for Percona Live UK coming up in 2 weeks from now and realize there's quite a smorgasbord of High Availability talks. What's more interesting, I see that we will be presenting some opposite opinions for the audience to digest:
- Istvan Podor will talk about Keep your MySQL backend online no matter what, and the abstact reveals his tool of choice for that is MMM.
- Yoshinori Matsunobu will be presenting his recently released MHA scripts in MHA: Introducing automated MySQL Master Failover solution
- Yours truly will be presenting Choosing a MySQL Replication / High Availability Solution. If you've been reading my blog, you already know that I will advice the audience to choose a solution that is based on synchronous replication and also advising against clustering frameworks such as MMM and MHA. Fight, fight, fight...! To be fair to Istvan and Yoshinori, both of them will be presenting good results from actual production environments with a measured 99.99% uptime.
- Oli Sennhauser has a title similar to mine: Various MySQL High Availability Solutions. The abstract does not reveal if he has a personal opinion and if he will share it or take a neutral position. I know we at least share the same opinion of one clustering framework, Corosync :-)
If you look at talks given by vendors who also sponsor the conference, we also find quite a few talks from Tungsten, the keynote from Clustrix, a talk from Schooner, all of which are solely are mostly offering a high availability solution too. And we shouldn't forget two talks on MySQL Cluster.
Update: Interestingly, I did not catch that Codership is also presenting their Galera 1.0 release.
I've said for some time that I think replication and high availability (but also replication for scale-out) is the new hot topic in the MySQL world and perhaps database world in general. This is comparable to how everyone was concerned about scale-up performance circa 2008, when multi core hardware architectures became mainstream - we've since solved those scalability issues, now high availability and replication is the new focus. This is good, it's an area that is not easy to solve, but where we can do better.
We now have great performance. We have online backups with xtrabackup. Remember all the different and awkward ways you used to do backups? I'm confident we can also find a HA solution that is a pleasure to use and that won't lose data. The next generation of DBA's will not even be aware there used to be such a concept as "planned downtime" :-)
PS: I'm also giving a talk on Drizzle: Fixed in Drizzle: No more GOTCHA's. This is my favorite Drizzle talk that I've originally heard Stewart giving. My favorite Gotcha that isn't in Drizzle anymore are the .frm files. Come and tell me what your favorite is.
If you didn't buy a ticket already, you can use the Drizzle discount code DrizzlePLUK to save 40£.
- Log in to post comments
- 13919 views
MySQL HA
I guess you are right Hingo, corosync (with pacemaker) is to my sense the way to go for MySQL HA.
I didn't have time yet to have a look at it but MHA could probably be also used as backend for an OCF ?
I hope the see your talk and share some ideas (with one or two beers ;) )
Don't like corosync either :-)
Actually, if you click the "read my blog" link, you'll find that I'm no fan of Corosync either. Your question actually points to a major reason why. The answer is, no it's not possible.
The point with MHA is that if you have a number of slaves, it will a) look into each of them to see who's relay log has received the most recent transactions, b) elect that slave as the new master, c) point all other slaves to the new master and start replication from the correct position (which is different for each of them).
Corosync (or OCF) doesn't allow the agent scripts to do any of that. In these clustering frameworks it is the framework that chooses where to failover, and the MySQL specific agents you write are supposed to just implement that decision. There is no opportunity to give any input to the clustering framework, such as a hint that it should choose a particular slave that is most up to date in order to minimize data loss. Well, in fact you must choose that slave, otherwise you end up with inconsistent replicas. But Corosync doesn't know anything about these problems, so it will just blindly choose a new master for you.
From this it follows that at least MMM and MHA are preferable to a "dumb" general clustering framework like Corosync. They at least try to understand how MySQL behaves and what you need to do for correct failover. But they share all the other shortcomings of an external clustering framework.
Talks accepted for their own merits
Your wording seems to imply that we have bought the talking slots.
If that thought has crossed your mind, please be aware that one talk was granted because of sponsorship, and two were accepted for their own merits through regular submission to the CfP.
That is correct, and I tried
That is correct, and I tried to choose a wording that doesn't contradict it. (Some, like the sponsored keynote, are of course sponsored. But per Percona policy, also they are 100% technical.) If it was still ambiguous, then thanks for clarifying.
In any case, the talks listed in that part are about a particular product, which may also cover more than just replication and ha (such as performance).
mysql ocf
You are right regarding the current OCF, but I've seen very complex OCFs, not yet for mysql (or not yet released) that could perform all those steps too. Corosync is the "message" and monitoring platform, but then you are free to write all the behaviour you need in your OCF... let's discuss this in 2 weeks.
Cheers.
That would then be an
That would then be an important improvement. I'm interested to learn more.