Now you may not believe me, but there actually are situations when DRBD is not the right choice for meeting your storage needs. Since I’ve been asked to compile some of these and present them here, let’s take a look.
Don’t use DRBD when…
- All or most of your data is static. Front-end web servers are a prime example for this. Even though they usually serve highly dynamic content these days, your PHP documents and Perl scripts and JSP‘s usually don’t change that often. Using DRBD for that type of data isn’t much use. Use DRBD for your backend store instead. On the front end, you’ll do fine with rsync, although it doesn’t scale well for large sets of files. Give csync2 a shot.
- Your application requires sub-second failover. If you you deploy DRBD in active/passive (failover) mode, expect Heartbeat, RHCS, or the other cluster manager of your choice to take around 15-20 seconds for failover. Any subsequent recovery procedures by your application may add to that. It’s highly unlikely that you’ll go beyond 1 minute failover time when your setup is properly done, but if that really is way too much for you, turn away from DRBD/Heartbeat. For example, for databases, get MySQL Cluster, or Oracle RAC. By the way you can use DRBD for the latter, just not with Heartbeat.
- You are required to provide synchronous 3-way redundancy. In some environments, by legal requirements 2-node automatic failover is just not enough. Many aviation systems are an example, to my knowledge, as are life support systems in health care. For the time being, DRBD doesn’t go beyond 2 nodes synchronously (DRBD+does support 3 nodes, but that feature is for disaster recovery, not 3-way failover).. Edit: I wrote this post long before the release of DRBD 8.3. Since 8.3, DRBD is entirely suitable for use with synchronous replication across as many as 4 nodes.
- You only need replication for one particular purpose, and want extreme optimization. If, for example, a MySQL database is the only thing you’re ever going to replicate, you may be better off using MySQL replication. It’s pretty challenging stuff getting it to work with a master-slave setup that does automatically and reliably switch roles on node failure, but admittedly in enables you to do some advanced things DRBD doesn’t offer. If, however, you’re thinking about replicating PostgreSQL and Oracle and Samba and NFS and Xen backend devices too, then, well, DRBD may be not that bad a choice after all.
- You dislike your boss, and love anything that may cut into his or her bonus. Isn’t a pair of synchronous replication capable SAN boxes a lovely huge item on any hardware bill?
Florian's blog 
This is a good article and makes a lot of sense
I have used DRBD with LAMP stacks and mysql very effectivly for some fairly large scale projects,with scheduled mysql db hot copies from a slave,running hourly and a remote location for DR and of course we use RSYNC the static stuff as well.
John, you mean you have a 2-node DRBD-backed MySQL master and several slaves pulling replicated databases off of it? Yes, that is a very common type of setup.
[…] When not to use DRBD « Florian’s blog – January 23rd ( tags: drbd cluster mysql linux storage tips tricks ) […]
What if i want to build a DR site of running ORACLE R12 using DRBD.
Is it better to use DRBD for Oracle EBS R12 ?
Thank you very much for this blog. That’s what I like about open source: you here the truth (if a solution does not fit)
Florian, For failover within a second on a RHCS zabbix/postgres cluster would one need to use a SANS in place of DRBD?
Nope, if you want sub-second failover a SAN doesn’t help, and certainly not any more so than DRBD. What you would need is application-level consistency, and possibly cache synchronization, so all you’d need to do is shift over the virtual IP. RHCS has no provisions for achieving that.