Re: master-> 2 hot standbys - Mailing list pgsql-general

From Ben Chobot
Subject Re: master-> 2 hot standbys
Date
Msg-id D3E81DE6-8B58-4E43-A368-2199FABD1161@silentmedia.com
Whole thread Raw
In response to master-> 2 hot standbys  (Julie Nishimura <juliezain@hotmail.com>)
Responses Re: master-> 2 hot standbys  (Julie Nishimura <juliezain@hotmail.com>)
Re: master-> 2 hot standbys  (Julie Nishimura <juliezain@hotmail.com>)
List pgsql-general

On Mar 4, 2019, at 1:59 PM, Julie Nishimura <juliezain@hotmail.com> wrote:

Hello,
Our current master 9.2 has two active standbys. Can you please help me out with the right sequence of events if we would like to promote one of current standbys to master and convert master to standby? 

It depends on how you've set things up, of course, but generally you can run "pg_ctl promote" on one of your slaves. This will make that slave start a new timeline and begin to act as a master. To restore your old master to a standby, you will need to rebuild it with something like pg_basebackup, as I do not believe pg_replay is supported with 9.2.


Terminating client connections on the old master to avoid splitbrain and then making those clients reconnect to your new master is left as an exercise to the reader - how you do it really depends on your environment - but be sure you do it right, because splitbrain is a real danger. In a similar vein, you don't want two masters trying to save the same wals to the same wal archive. 

Also, if your two slaves are using asynchronous replication, be aware that the slave you choose to become the new master has a chance to be behind the other slave in wal replay when you promote it, unless you take precautions. This would mean your other slave won't be able to sync up with the newly promoted master.

pgsql-general by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Question about pg_upgrade from 9.2 to X.X
Next
From: Martín Fernández
Date:
Subject: VACUUM FREEZE and replication lag