We are in the process of implementing a new CMS (Drupal 6.x) that runs on MySQL. We have two data centers -- primary and secondary -- with known latency between them. We're unsure which version of MySQL we will run ... either Community or Enterprise, but that is a TBD. Looks like we will be running the InnoDB engine, OS is going to be RedHat EL 5.5 The primary servers are going to be active, while the secondary will be passive or hot stand-bys.

I would like to implement replication, high availability and automated failover in MySQL across the two data centers.

After a failover to the secondary servers, when we fail-back to the primary servers, we'd like to have data synched from the secondary DB to the primary DB quickly and completely so that we can continue to serve content from the primary servers.

I am interested in knowing what technologies/tools/best practices can be used to solve/address these issues. Also, any gotchas or ah-ha moments would be much appreciated as well. I've read up on MySQL replication, clustering, and at some 3rd party tools like Tungsten and Dolphinics, but I a unsure what the is best course of action.

Thank you for your time!


1 Answer 1


For the sake of simplicity, I recommend MySQL Circular Replication only. Here is why:

There are many technologies and topologies that are far superior to MySQL Circular Replication. My favorite, hands down, is DRBD (Distributed Replicated Block Device). However, DRBD works great when the Server Pair is in the same bulding, data center, and rack. It's even better when using a crossover cable in the 192.168.x.x. subnet between the DRBD Primary and DRBD Secondary. Unfortunately, DRBD has horrible performance over a distance between two locations, although DRBD can still work. There are no network topologies around to give you the satisfactory DRBD performance needed between two datacenters.

Once you setup MySQL Circular Replication between the two DB servers in two different data centers, the only tuning needed is for the network. In essence, the replication performance is a function of network settings (speed/latency of binary log transmission in MySQL Replication Setup) and disk I/O (DRBD).

An alternative you may want for better redundancy is the following for the sake of example:

Setup a DRBD Pair in both locations
DRBD Pair in Site #1 with VIP
DRBD Pair in Site #2 with VIP

Setup MySQL Circular Replication between the DRBD Primary Servers under these conditions:
For site #1, use as the Master_Host in MySQL
For site #2, use as the Master_Host in MySQL

Although introducing a level of complexity, now you have two levels of redundancy: DRBD within each site and MySQL Circular Replication between sites. You have the additional benefits of running backups via mysqldump on the DRBD Primary of the hot standby server.

As for failover, DRBD provides automatic failover at any one site.

Only in the event that a datacenter is totally unavailble would you using the DB VIP at the hot standby site.


I just did a double take and noticed that you are using Drupal6. I am glad you will be converting all the drupal tables to InnoDB. This will remove any chance of MyISAM table updates causing table locks to freeze DB Connections that are simply reading MyISAM tables. Any DML update (INSERTs, UPDATEs, DELETEs) against a MyISAM table WILL ALWAYS DO A FULL TABLE LOCK !!! Using InnoDB will introduce row-level locking, which eliminates full table locks.

In addition, DRBD becomes your friend when everything is InnoDB because crash recovery will be consistent between the DRBD Pair. Contrawise, DRBD with MyISAM buys you nothing because a crashed MyISAM table on the DRBD Primary is simply duplicated to the DRBD Secondary as, you guessed it, a crashed MyISAM table.


You should use two levels of redundancy

Level 1 : At each database center, use DRBD.

Set up a pair of DB Servers
Startup DRBD
Startup MySQL on the DRBD Primary

This creates redundant data at the disk level.

Level 2 : You should setup MySQL Circular Replication between
the DRBD Primary of DataCenter#1 and the DRBD Primary of DataCenter#2

Each DRBD Primary will be running MySQL and will act
as both Master and Slave to Each Other

I have setup for clients topologies like this and I consider it quite stable.

  • Thanks @RolandoMySQLDBA. Your point about using a load balanced VIP for datacenter outages makes sense. So we would have a Master-Slave in each datacenter, right? In the event of fail-back, what do you think is the best way to ensure the primary DBs is up-to-date? Also, I've been looking at circular replication, and that looks like it is based on MySQL clustering? with NDB? I don't think Drupal 6 works well with NDB (drupal.org/node/391130). Thank you again for your time!
    – KM.
    Mar 30, 2011 at 20:27
  • I have updated my answer !!! BTW I never mentioned NDB. MySQL Circular Replication is just Master-Slave implemented bidirectionally. Mar 30, 2011 at 20:43
  • Thanks for the clarification. Some of the MySQL circular replication references mentioned NDB so I wanted to double check (-: BTW, How automated can you get with failover using these topologies?
    – KM.
    Mar 31, 2011 at 20:21
  • DRBD is designed to facilitate automatic failover using either Linux HeartBeat or ucarp (ucarp.org/project/ucarp). My company, LogicWorks, is a ucarp shop. ucarp allows two machines to share one virtual IP (VIP) address. DRBD Master would have the VIP with MySQL running on it. DRBD Secondary would have ucarp running and wait for a dead ratio of time to trigger automatic failover. The up and down scripts for ucarp to assume the DB VIP should include mounting the DRBD disk, making it Primary, and starting MySQL. Down script would stop MySQL unmount DRBD, go Secondary and kill the VIP. Mar 31, 2011 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.