DRBD Users Guide 8.0-8.3

Using Heartbeat with dopd

The steps outlined in this section enable DRBD to deny services access to outdated data. The Heartbeat component that implements this functionality is the DRBD outdate-peer daemon, or dopd for short. It works, and uses identical configuration, on both R1-compatible and CRM clusters.


It is absolutely vital to configure at least two independent Heartbeat communication channels for dopd to work correctly.

Heartbeat configuration

To enable dopd, you must add these lines to your /etc/ha.d/ha.cf file:

respawn hacluster /usr/lib/heartbeat/dopd
apiauth dopd gid=haclient uid=hacluster

You may have to adjust dopd's path according to your preferred distribution. On some distributions and architectures, the correct path is /usr/lib64/heartbeat/dopd.

After you have made this change and copied ha.cf to the peer node, you must run /etc/init.d/heartbeat reload to have Heartbeat re-read its configuration file. Afterwards, you should be able to verify that you now have a running dopd process.


You can check for this process either by running ps ax | grep dopd or by issuing killall -0 dopd.

DRBD Configuration

Then, add these items to your DRBD resource configuration:

resource resource {
    handlers {
        fence-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
    disk {
        fencing resource-only;

As with dopd, your distribution may place the drbd-peer-outdater binary in /usr/lib64/heartbeat depending on your system architecture.

Finally, copy your drbd.conf to the peer node and issue drbdadm adjust resource to reconfigure your resource and reflect your changes.

Testing dopd functionality

To test whether your dopd setup is working correctly, interrupt the replication link of a configured and connected resource while Heartbeat services are running normally. You may do so simply by physically unplugging the network link, but that is fairly invasive. Instead, you may insert a temporary iptables rule to drop incoming DRBD traffic to the TCP port used by your resource.

After this, you will be able to observe the resource connection state change from Connected to WFConnection. Allow a few seconds to pass, and you should see the disk state become Outdated/DUnknown. That is what dopd is responsible for.

Any attempt to switch the outdated resource to the primary role will fail after this.

When re-instituting network connectivity (either by plugging the physical link or by removing the temporary iptables rule you inserted previously), the connection state will change to Connected, and then promptly to SyncTarget (assuming changes occurred on the primary node during the network interruption). Then you will be able to observe a brief synchronization period, and finally, the previously outdated resource will be marked as UpToDate again.