I think DRBD mainly applies to the people who mainly got use to SAN based clustering and active-passive clustering offered by many databases. It is generic and this is what some groups of people love.

Florian
is replying to Janmes on the subject of using DRBD for MySQL HA. Florian is refuting most of the arguments that James has against using MySQL and DRBD together.

I`m also saying NO to MySQL and DRBD in most of the cases.. but not for any of…

“DRBD partition corruption means failover node would be unusable (disadvantage of shared storage) and failback could destroy original master too.”

If the filesystem that sits on DRBD gets corrupted, it is correct that that corruption wouldn’t magically disappear on failover. However failback can’t “destroy” the master (i.e. cause more corruption than already exists).

“If the master panics, then after failover both fsck and transaction logs replay must be performed.”

fsck amounts to replaying a journal and usually gets completed within under a second. Unless you use a non-journaling filesystem, which is a really bad idea in the first place. And while DRBD would panic the host deliberately in some error conditions in obsolete versions, it doesn’t do so anymore (since DRBD 8, which was released over a year ago).

“NIC and network corruption is also propagated.”

Wrong. End-to-end replication integrity checking was introduced to prevent exactly that. This has been around for half a year. See http://www.drbd.org/users-guide/s-integrity-check.html

“Failover node is a cold standby, cannot accept database traffic if that would change the DRBD partition”

Correct, but nothing stops you from running two DRBD-backed database instances on two hosts in a “criss-cross” fashion, converging on one node on node failure.

“Could generate a lot of network traffic.”

Which is why it’s always recommended to use a dedicated crossover replication link.

“2 heartbeats needed on a reliable, local network.”

2 network connections are always available if you follow the recommendation above. Adding another heartbeat communication path amounts to adding one line in a config file.

And allow me to add two more pluses here for DRBD, just because a customer mentioned them in one of the DRBD sessions at the conference:

1. No matter on which host a DRBD-backed MySQL server runs, it listens on a virtual, Heartbeat-managed IP address. Thus if you run 1:n replication off that master, failing over doesn’t affect replication to your slaves at all. It simply continues right where it left off after failover and manual switchover.

2. DRBD is synchronous. Can’t do that with MySQL replication.