Re: Assistance with documenting a failover / fallback process that maintains replication

Hi Mike,

If I were you, I would use a replication manager like Patroni or repmgr. A
replication manager will handle all of the Postgres steps for you including
auto failover if the primary fails and a planned switch over from the
primary to the standby with a single command. Personally, I prefer
Patroni but it all depends on your environment.

Best Regards,
Tim

On Sat, Feb 1, 2025, 10:26 AM Hall, Michael H. (GSFC-423.0)[RAYTHEON
COMPANY] <michael(dot)h(dot)hall-1(at)nasa(dot)gov> wrote:

> I’ve had the good fortune to be able to quickly use the PG14 replication
> to promote my secondary server recently.
>
>
>
> Before my primary had a HW failure, I been not aware that I needed to have
> replication configured on the primary (to obtain data when the secondary
> was promoted).
>
>
>
> I’m hoping that someone who’s more familiar with process could review
> items below to make sure that I haven’t missed something.
>
>
>
> *Returning operations to Primary Server*
>
> Following is an "order of operations":
>
> 1. Confirm that replication running on both servers.
> 2. Have Ops stop application.
> 3. Stop Postgres on db02 (temporary primary DB server).
> 4. Promote db01 to primary server using "pg_ctl -D $PGDATA promote"
> command
> 5. Edit PostgreSQL.conf file on db02. Change parameter "hot_standby
> = on".
> 6. Create a file "standby.signal" in $PGDATA directory on db02.
> 7. Start Postgres on db02.
> 8. Confirm that replication is running from db01 to db02
>
> I believe that part of my problems were caused by not doing steps 5 and 6
> before step 7.
>
>
>
> Also, if anyone has some procedures for re-establishing replication if it
> fails… it would be a great help.
>
>
>
> Thanks in advance.
>
> --
>
> Michael H. “Mike” Hall, Sr. NASA-GSFC
>
>
>
>
>