Stephan Hahn

The problem seems to be that a standby doesn't know whether another standby has already done a failover, if it wasn't reachable during this promotion. Because the order of server...

I cannot reproduce the described behavior any longer, probably there went something wrong before, or maybe due to newer versions. Although there still may be two failovers at almost the...

Hi, the LSN should be more important, regardless of the fact that you have always some kind of priority that results from the different node ids. Regards Stephan

https://github.com/2ndQuadrant/repmgr/blob/master/doc/repmgrd-node-fencing.md

@grishin-a I assume if you shutdown 3 of 5 nodes, there's no remaining majority of servers, so the failover doesn't take place. But maybe sometimes it would be desirable that...

@pierhommedba in your config file of node 45 the priority is 100, but with repmgr cluster show it is 45. It looks like you have not registered the standby again...

You could try to copy the file from another location (wal archive) to pg_wal before the rejoin.

I think you have to start the database first. Only then you can start repmgrd or register the standby.

yes, it seems one has to reregister the standby in this case. But when you reboot the server, repmgrd ist always stopped before Postgres

Hi, there is no inbuilt automatic rejoin. By just starting the old master again, you create a split brain scenario. But it's no problem to automatically rejoin the old master...