Downgrading to DRBD 8.3

A popular question to pop up on the drbd-user mailing list is how to downgrade from a DRBD 8.4.x installation to DRBD 8.3. Luckily, the developers haven't made this hard; there's just one specific thing you'll have to remember. We'll show you how to do this.

The DRBD metadata format between is largely compatible between DRBD 8.3 and 8.4, however there has been a change to the Activity Log (AL) – and that means that DRBD 8.3 can't immediately use a metadata set that was previously created under, or converted to, DRBD 8.4.

Thus, if your AL is cleanly "applied", then DRBD 8.3 will load the metadata just fine – if it's not, then it'll fail to attach.

There are two ways of fixing this. Note that both of them require that you bring the entire DRBD resource (both peers) down temporarily; there is no provision for a rolling downgrade. So be sure to schedule a maintenance window if this affects a production system.

The apply-al trick

This method is for you if you still have DRBD 8.4 utilities and the kernel module installed, before you start the downgrade procedure. Here's how it works; all of the steps listed here have to be completed on both nodes:

• drbdadm down all
  drbdadm apply-al all
  modprobe -r drbd

• Uninstall DRBD 8.4 utilities and kernel module.

• Install DRBD 8.3 utilities and kernel module.

• Fix your DRBD configuration to clean any DRBD 8.4 specific syntax. In essence, apply the considerations from the Recent Changes to 8.4 in reverse.

• Check your configuration with drbdadm dump all.

• modprobe drbd

• Examine /proc/drbd to ensure your kernel has in fact loaded 8.3.

• drbdadm up all

No other changes should be necessary to your configuration.

The create-md/new-current-uuid trick

This is the backup option; note the the apply-al method remains preferred.

This method is for you if you've already uninstalled your DRBD 8.4 packages, you can't be convinced to reinstall them, and you're certain that your peers were in sync when you downed them. The last part is really important, don't do this if there is even the slightest chance that they were out of sync.

In essence, this amounts to freshly reinitializing the DRBD metadata, and then skipping the initial sync as you already know they peers don't need to be synchronized. Here's how it works:

• Install DRBD 8.3 utilities and kernel module.

• Fix your DRBD configuration to clean any DRBD 8.4 specific syntax. In essence, apply the considerations from the Recent Changes to 8.4 in reverse.

• Check your configuration with drbdadm dump all.

• drbdadm create-md all

• modprobe drbd

• Examine /proc/drbd to ensure your kernel has in fact loaded 8.3.

• drbdadm up all

• Your devices will now come up as Secondary/Secondary and Inconsistent/Inconsistent, as any freshly initialized DRBD device.

• On only one node (really, don't do this on both) issue this command:

  drbdadm -- --clear-bitmap new-current-uuid all

• Your devices should now still be Secondary/Secondary, but their disk states should have changed to UpToDate/UpToDate.

Now, you're able to make your devices Primary again, and put them back under Pacemaker management.