In the following section, we provide answers to questions that are most frequently asked about DRBD Architecture.
188.8.131.52: How long does a failover take?
184.108.40.206: How long does it take to resynchronize data after a failure?
220.127.116.11: Are there any situations where you shouldn't use DRBD?
18.104.22.168: Where can I find more information on sample architectures?
22.214.171.124: Is an Active/Active option available for MySQL with DRBD?
126.96.36.199: Are there any limitations to DRBD?
188.8.131.52: What MySQL storage engines are supported with DRBD?
Questions and Answers
Failover time is dependent on many things, some of which are configurable. After activating the passive host, MySQL will have to start and run a normal recovery process. If the InnoDB log files have been configured to a large size and there was heavy write traffic, this may take a reasonably long period of time. However, under normal circumstances, failover tends to take less than a minute.
Resynchronization time depends on how long the two machines are out of communication and how much data was written during that period of time. Resynchronization time is a function of data to be synced, network speed and disk speed. DRBD maintains a bitmap of changed blocks on the primary machine, so only those blocks that have changed will need to be transferred.
See When Not To Use DRBD.
For an example of a Heartbeat R1-compatible resource configuration involving a MySQL database backed by DRBD, see DRBD User's Guide.
For an example of the same DRBD-backed configuration for a MySQL database in a Heartbeat CRM cluster, see DRBD User's Guide.
Currently, MySQL does not support Active/Active configurations using DRBD “out of the box”.
All of the MySQL transactional storage engines are supported by DRBD, including InnoDB and Falcon. For archived or read-only data, MyISAM or Archive can also be used.