It seems pretty common to find customers install DRBD for the wrong reasons. There are many pros/cons to compare DRBD to replication, but I’ve managed to cut down my spiel I give to customers to these two points:
- DRBD’s aim (assuming replication mode C) is to provide 100% consistency, and then as much uptime as possible.
- MySQL Replication (with a manager such as MMM) aims to have 100% availability, at the potential loss of some data surrounding a failure.
So if you are installing DRBD with the aim of purely “availability”, and are not worried about losing that last write on the crash to your master database that (hopefully) happens only once every few years, you may be using the wrong technology.
While the prized “1 minute failover” is possible in DRBD, it doesn’t really explain the full picture. The typical crash recovery process in DRBD is a lot longer:
- After resource transfer, a filesystem check runs (0-5 seconds).
- mysqld is started (1-5 seconds)
- InnoDB runs through crash recovery (1 minute – several hours). Peter wrote about this here.
- The server is then ready to accept connections.
Now, having said that: If you have an application that requires 100% consistency, then DRBD is one of your best choices on the mysql-market today.