Skip navigation links
A.14.4 DRBD and MySQL Replication »
Section Navigation      [Toggle]

A.14.3. DRBD Architecture

In the following section, we provide answers to questions that are most frequently asked about DRBD Architecture.

Questions

  • 23.14.3.1: How long does a failover take?

  • 23.14.3.2: How long does it take to resynchronize data after a failure?

  • 23.14.3.3: Are there any situations where you shouldn't use DRBD?

  • 23.14.3.4: Where can I find more information on sample architectures?

  • 23.14.3.5: Is an Active/Active option available for MySQL with DRBD?

  • 23.14.3.6: Are there any limitations to DRBD?

  • 23.14.3.7: What MySQL storage engines are supported with DRBD?

Questions and Answers

23.14.3.1: How long does a failover take?

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.

23.14.3.2: How long does it take to resynchronize data after a failure?

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.

23.14.3.3: Are there any situations where you shouldn't use DRBD?

See When Not To Use DRBD.

23.14.3.4: Where can I find more information on sample architectures?

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.

23.14.3.5: Is an Active/Active option available for MySQL with DRBD?

Currently, MySQL does not support Active/Active configurations using DRBD “out of the box”.

23.14.3.6: Are there any limitations to DRBD?

See DRBD limitations (or are they?).

23.14.3.7: What MySQL storage engines are supported with DRBD?

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.


User Comments

Posted by Ben Clewett on March 11 2008 8:16am[Delete] [Edit]

There are two limits with DRBD we have noticed.

Firstly, write latency is a bit higher. This can be tuned by selecting which DRBD protocol to use where A is fastest and C is slowest but has highest integrity. But this is hardly noticeable.

Secondly there is the bottleneck of the network linking your serves. Eg, a dedicated 1000baseT cannot exceed about 100MB/sec write. Read is unaffected. This can effect restoring backups and large data imports.


Posted by Steve Wegner on April 23 2009 7:32pm[Delete] [Edit]

Based on a support case I had open.
If you are using InnoDB AND DRBD AND doing a lot of writes, this may help you. Bear in mind you could lose up to 1 second of data in a failure.

innodb_flush_log_at_trx_commit = 0 (Default is 1)

This will cause InnoDB to only write and flush the log buffer once per second. This allows it to combine writes to both DRBD and local disk for maximum performance. It
does risk the chance of a crash causing you to lose up to 1 second worth of unwritten data. This is discussed at:
http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

Add your own comment.