Scott M. Mcdermott

UNIX Systems & Network Administrator
available for contract or salaried positions

PostgreSQL cluster using DRBD and hot standby

We document implementation of Database Redundancy using DRBD to replicate the block device and Red Hat Cluster Suite to manage which node has responsibility for providing the service. This implementation uses a hot-standby database which is preconfigured to assume database service duties immediately, failed over transparently to the application, and requires no administrative intervention.

The following sections follow the implementation from start to finish.


  • prerequisites

    Implementation begins with a RHEL5 system as the base platform. Two nodes are required. While it's not necessary for the nodes to be identical, using identical systems is recommended. For failover purposes, however, it's often enough to be able to provide service at all, not necessarily at the same performance capacity.

  • drbd

    The clustered block device is provided to PostgreSQL with DRBD. This involves creating component devices which will underly the replicated volume, configuring the network connection between the replication nodes, and configuring policies for DRBD to behave a certain way in response to the various events which can effect connectivity between the replicant nodes.

  • postgresql

    The redundant PostgreSQL service layer is built on top of DRBD. Now that we have the basic building block of replication -- the actual replicated data, implemented as a replicated DRBD volume -- we have to create an identical PostgreSQL instance on each machine that will use our DRBD device to house its datafiles.

  • cluster

    To provide High Availablity we automate the process of failover with a Cluster Manager. Both nodes are now identically configured, have identical copies of the data, and can act as the database server. Doing this automatically in the event of failure is the job of a Cluster Manger.