From: | Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com> |
---|---|
To: | "Jehan-Guillaume (ioguix) de Rorthais" <ioguix(at)free(dot)fr> |
Cc: | MirrorX <mirrorx(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: switchover/switchback |
Date: | 2019-03-03 06:23:57 |
Message-ID: | CAGDYbUNKSaK34-=H-Mg=fQuE-J2h-RHmx=Y2wUpocAQtZ474sA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Go through the link for more details.
https://repmgr.org/docs/4.0/performing-switchover.html
Thanks & Regards,
*Shreeyansh DBA Team*
www.shreeyansh.com
On Sat, Mar 2, 2019 at 1:19 PM Jehan-Guillaume (ioguix) de Rorthais <
ioguix(at)free(dot)fr> wrote:
> On Sat, 2 Mar 2019 10:24:21 +0530
> Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com> 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(at)gmail(dot)com> 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,
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jehan-Guillaume (ioguix) de Rorthais | 2019-03-03 13:44:48 | Re: switchover/switchback |
Previous Message | Anjul Tyagi | 2019-03-02 11:41:55 | Re: Install Barman on SUSE |