I have used many tools starting with MMM to be able to manage MySQL replication clusters. Some of the tools need more tools and complex HA solutions such as Pacemaker and Corosync, or Zookeeper. While other tools do not do the failover well which leaves the slaves in an inconsistent state, MMM would be an example. And I must say that of all the tools I love MySQL Master HA (MHA) the most. MHA is a great tool to manage MySQL replication clusters for the purpose of HA. The most important thing about MHA is that it tries to take all the necessary steps to do a MySQL master failover in a way that provides as much data consistency as possible. The slave promotion also tends to be very quick, on average I have seen it take 10 to 15 seconds. It is also very easy to deploy unlike some of the other complex HA solutions. I would highly recommend reading about the architecture of MHA on its wiki: https://code.google.com/p/mysql-master-ha/wiki/Architecture Why …

There were two nasty MySQL replication bugs in two different 5.6 releases that would make it difficult to upgrade slaves to MySQL 5.6 while still connected to MySQL 5.5 master. The first of those bugs is MySQL bug 72610 which affects 5.6.19. Essentially this bug is triggered when the table structure on the slave is different from the table structure on the master which leads to unnecessarily large amount of RAM usage while replicating events that affect that table. The amount of RAM used would generally be more noticeable when the replicated transaction consists of thousands of RBR events. The most common way this affects how we upgrade a replication hierarchy, is when we have the master running MySQL 5.5 and the slave running MySQL 5.6 and we have transactions involving DATETIME column(s). Tables with DATETIME columns will have different underlying structure when created on MySQL 5.5 versus when created on MySQL 5.6. Ideally you would avoid creating …