MIME-Version: 1.0
From: Pratik Pandit <pratikpandit5322@gmail.com>
Date: Wed, 3 Jun 2026 23:56:36 +0530
Message-ID: 
 <CAFchsDXBY69YVYuke-9zxZubqE1hW7oZj=vDYwNyUhuxWyvAYA@mail.gmail.com>
Subject: Configuring Pacemaker constraints for Postgres on Shared Storage
To: pgsql-admin@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000018cda806535d928c"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFchsDXBY69YVYuke-9zxZubqE1hW7oZj%3DvDYwNyUhuxWyvAYA%40mail.gmail.com>
Precedence: bulk

--00000000000018cda806535d928c
Content-Type: text/plain; charset="UTF-8"

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

--00000000000018cda806535d928c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi all,</p><p>I am configuring a 2-node Pacemaker clust=
er 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.</p><p>I want to=
 ensure my Pacemaker colocation and ordering constraints are mathematically=
 airtight to prevent split-brain.</p><p>Currently, I am planning the follow=
ing resource group/constraints:</p><ol start=3D"1"><li><p>Virtual IP (<code=
>IPaddr2</code>)</p></li><li><p>Filesystem Mount (<code>Filesystem</code>)<=
/p></li><li><p>PostgreSQL Service (<code>pgsql</code>)</p></li></ol><p>My q=
uestions for the community:</p><ul><li><p>Is it safer to group these resour=
ces together so they always migrate as a single unit, or handle them via ex=
plicit <code>colocation</code> and <code>order</code> constraints?</p></li>=
<li><p>When using distributed storage, how do you handle the <code>postgres=
ql.conf</code> parameters like <code>archive_command</code> or tracking rep=
lication states when the secondary node boots up using the exact same data =
directory bytes as the primary?</p></li><li><p>If you have a working boiler=
plate XML or <code>pcs</code> command template for a shared-storage Postgre=
s setup, it would be incredibly helpful.</p></li></ul><p>Appreciate any ins=
ights or pitfalls to avoid!<br></p><p>Thanks</p><br></div>

--00000000000018cda806535d928c--