Re: Speed up Switchover - Mailing list pgsql-general

From Andres Freund
Subject Re: Speed up Switchover
Date
Msg-id 20130726065442.GA13646@alap2.anarazel.de
Whole thread Raw
In response to Re: Speed up Switchover  (Sergey Konoplev <gray.ru@gmail.com>)
List pgsql-general
On 2013-07-25 22:00:23 -0700, Sergey Konoplev wrote:
> On Thu, Jul 25, 2013 at 1:03 AM, TJ <tj@wallago.co.uk> wrote:
> > I am looking for a way of speeding up the process of switching over of
> > severs.
> > At the moment we are switching over via the trigger file, reconfiguring our
> > applications, patching or updating the old primary and rsyncing the data
> > over to the old primary.
> >
> > I was wondering if there was an easier way to get the primary setup as a
> > secondary without having to rsync the data as it can take up to 10 hours.
>
> pg_rewind (https://github.com/vmware/pg_rewind) is what you need.

Beside the issue pointed out by Robert (via Samrat), it's also for 9.3
onwards only...

If it's a planned failover you can do better by shutting down the
servers manually...

a) shutdown master gracefully (i.e. -m fast, not immediate)
b) use pg_controldata to check for the last wal location
c) verify that the standby has received WAL up to that point, otherwise
   restart from a)
d) shutdown standby
e) remove recovery.conf on the standby, thus "silently" promoting it
f) start previous standby, now as master
g) create recovery.conf on the previous master
h) start previous master, now a standby

Note that you're deliberately circumventing security measures that way,
you need be rather careful to understand the reasoning behind those
steps and follow them carefully. But it allows to gracefully failover &
follow in large clusters with only very short outages.
From 9.3 onwards you don't even need d) and e) anymore and you can
replace it with a regular promotion which will be noticeably faster.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-general by date:

Previous
From: Joe Van Dyk
Date:
Subject: Re: how _not_ to log?
Next
From: Joe Van Dyk
Date:
Subject: Re: casting tsrange to tstzrange doesn't seem to work?