The only things we should need at this point are the ability to run commands as root and a device dedicated to database storage. However, if you are running a RHEL system (not a derivative such as CentOS or Scientific Linux), you may need to contact Red Hat to obtain necessary licenses and packages to add XFS functionality. Thus, we will approach this recipe under the assumption that packages are available on Debian-based servers and RHEL derivatives.

To keep things simple, we will assume that each server we prepare has a device named /dev/sdb for database storage. Follow these steps as root:

In order for the stack to work properly, we need to get the server ready. For now, this means installing basic toolkits such as xfsprogs for XFS maintenance tools and drbd8-utils for DRBD administrative scripts. Once this is complete, we move on to preparing LVM.

Since LVM is so highly integrated into the system, we need to perform several steps. The first is to modify the primary lvm.conf file so that it only watches certain devices, and while it does so, it never caches the result. Due to the way Linux is designed, there are several different aliases and paths that point to the same device in the /dev filesystem. To remove these extra paths, we set a very strict filter that only includes /dev/sd* devices and /dev/drbd* devices.

We avoid caching by setting write_cache_state to 0 because the DRBD devices may disappear or reappear based on their statuses. We don't want an invalid cache poisoning the actual device state. Just to make sure there are no stale LVM caches, we remove the existing /etc/lvm/cache/.cache so that all readings are current. By invoking initramfs with the -u parameter, it generates a new device map that will be used when the system boots. This ensures that devices are consistent at all availability levels in case we need emergency access.

Before we venture further, we need to address performance. In Greg Smith's PostgreSQL 9.0 High Performance, Packt Publishing, he suggests that we increase the read_ahead_kb setting for every block device to 4096 kilobytes or higher. Unfortunately, due to the transient nature of our devices, there is no static method we can use that would survive a device appearing after boot. This is where the udev filesystem comes in. It watches as various system devices change state, appear, or reappear. Thanks to this, we can give it parameters to use when new storage devices appear, such as our DRBD or LVM devices.

The two lines we added to 20-postgresql.rules tell the udev filesystem to set the read_ahead_kb value to 4096 any time a new device is added or modified. In our case, we are specifically interested in the sdb and drbd0 devices, but we include all sd or drbd devices for future expansion purposes if necessary. This ensures that we'll always have a large read buffer for good PostgreSQL performance, no matter how many abstraction layers we place between the device and the database.

The last thing we do is reboot the server. This gives us a fresh slate, with a cleanly generated device map based on the changes we made.

The version of DRBD you receive with these instructions may vary considerably depending on the age of your distribution. As DRBD 8.4 is the most recent stable version at the time of writing this book, all recipes assume that this is the installed version. To see if you are using 8.4, execute drbdadm with the -V parameter, and check the module and tooling versions. If these versions don't match, or are 8.3 or below, please follow the instructions from one of these URLs to upgrade to 8.4: