0

My test environment had network glitch over the weekend and I ended up having two Primary databases up and running in the cluster.

 ID | Name                              | Role    | Status    | Upstream | Location | Priority | Connection string
----+-----------------------------------+---------+-----------+----------+----------+----------+------------------------------------------------------------------------------------
 1  | node-1 | primary | ! running |          | default  | 100      | host=node-1 user=repmgr dbname=repmgr connect_timeout=2
 2  | node-2 | primary | * running |          | default  | 100      | host=node-2 user=repmgr dbname=repmgr connect_timeout=2

Is there a way to demote the new Primary back to Standby and resume WAL shipping instead of perform the Standby clone?

PgSQL version: 10.7

Repmgr version: 4.3

Any help is greatly appreciated.

0

the bad news is: so far as I know the only solution is to demote one of your primaries and re-clone.

the good news is: rsync should be able to do the cloning fairly quickly if most of the data is unalteted,

  • Thanks for the reply. What command that you use for re-clone? I need to clean up the $PGDATA and tablespace directories for using the standby clone command: repmgr -h node-01 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --force --fast-checkpoint – CJ Chang May 21 at 10:50
  • my answer if from my understanding of postgresql, repmgr seems to be capable of using rsync, but I don't know enough abput its internals to give detailed instruction there. – Jasen May 22 at 23:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.