On Sat, Mar 2, 2019 at 1:19 PM Jehan-Guillaume (ioguix) de Rorthais <ioguix@xxxxxxx> wrote:
On Sat, 2 Mar 2019 10:24:21 +0530
Shreeyansh Dba <shreeyansh2014@xxxxxxxxx> wrote:
> Yes, this works, when your master goes down, you can promote a slave as a
> new master and to bring the old master in sync will have to rebuild it from
> the new master but manual intervention is there.
> You can achieve this by using the pgpool auto failover mechanism by adding
> your owned scripts as per your requirement to avoid the manual intervention.
OP is asking about switchover, not failover. Some are talking about "controlled
failover".
Note that OP is not (yet) asking about high availability here. You might be able
to do switchover with pgPool, but I would not recommend it as it requires to
write your own scripts all by yourself.
> On Fri, Mar 1, 2019 at 7:20 PM MirrorX <mirrorx@xxxxxxxxx> wrote:
>
> > starting with 9.3 i ve read on the EDB site about the possibility to
> > switchover/switchback in a controlled manner.
Yes, this is supported.
> > this way the current master is stopped, the slave is promoted to master and
> > then since the old master's xlog position is behind the new master's, it
> > can
> > be directly connected as a new slave without the need of it being rebuilt
> > and also without the need to use pg_rewind (since the xlog position hasnt
> > moved forward). this is been possible after 2 commits, the one about the
> > walsender sending all the xlogs to the slave when the master is being shut
> > down and the second is about the timeline and how the slave can continue
> > replicating when the timeline has changed.
Exact.
> > i have tested this many times and it has always worked. however, i find it
> > strange that there is little awareness about it and pg professionals that i
> > meet keep saying that the old master (new slave) needs to be rebuilt.
> > could someone clarify if this works and if not why it could potentially
> > fail?
This has been discussed few weeks ago on pgsql-hackers. This certainly deserve a
doc patch and maybe some useful tooling.
The only risk I am aware of, is a race condition were the
standby-to-be-promoted disconnect from the master during the shutdown (think
network issue or anything else). That's why you need to check on the standby if
it received the shutdown checkpoint from the old master before promoting it.
The procedure would be:
1. smart/fast shutdown the master
2. note the LSN of the shutdown checkpoint on the master
3. look for shutdown checkpoint on the standby @ noted LSN
4. if found, promote the standby
5. create the recovery.conf on the old master and start it
Regards,
