public inbox for [email protected]  

help / color / mirror / Atom feed

From: Pratik Pandit <[email protected]>
To: [email protected]
Subject: Configuring Pacemaker constraints for Postgres on Shared Storage
Date: Wed, 3 Jun 2026 23:56:36 +0530
Message-ID: <CAFchsDXBY69YVYuke-9zxZubqE1hW7oZj=vDYwNyUhuxWyvAYA@mail.gmail.com> (raw)

Hi all,

I am configuring a 2-node Pacemaker cluster to manage a PostgreSQL
instance. The architecture relies on an external distributed storage array.
Node 1 and Node 2 both see the block device, but only the active node
should mount it and start PostgreSQL.

I want to ensure my Pacemaker colocation and ordering constraints are
mathematically airtight to prevent split-brain.

Currently, I am planning the following resource group/constraints:

   1.

   Virtual IP (IPaddr2)
   2.

   Filesystem Mount (Filesystem)
   3.

   PostgreSQL Service (pgsql)

My questions for the community:

   -

   Is it safer to group these resources together so they always migrate as
   a single unit, or handle them via explicit colocation and order
   constraints?
   -

   When using distributed storage, how do you handle the postgresql.conf
   parameters like archive_command or tracking replication states when the
   secondary node boots up using the exact same data directory bytes as the
   primary?
   -

   If you have a working boilerplate XML or pcs command template for a
   shared-storage Postgres setup, it would be incredibly helpful.

Appreciate any insights or pitfalls to avoid!

Thanks

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Configuring Pacemaker constraints for Postgres on Shared Storage
  In-Reply-To: <CAFchsDXBY69YVYuke-9zxZubqE1hW7oZj=vDYwNyUhuxWyvAYA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox