Skip site navigation (1) Skip section navigation (2)

Re: Failback with log shipping

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failback with log shipping
Date: 2010-05-29 03:11:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, May 28, 2010 at 7:58 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> At PGCon, several people asked me about restarting an old master as a
> standby after failover has happened. And it wasn't the first time people ask
> me about it, even before 9.0. We have no mention of that in the docs, which
> is a pretty serious oversight. What can we say about it?
> I believe the current official policy is that you have to take a new base
> backup and restore from that. Rsync can be used to speed that up.
> However, someone once asked me for a comment on a script he wrote to do that
> in a smarter way. I forget who and when and how exactly it worked, but it
> seems possible to do safely.
> First of all, you have to shut down the master cleanly for this to work,
> otherwise there can be changes in the old master that never made it to the
> standby.
> Assuming controlled shutdown and that the standby received all WAL from the
> old master before it was promoted, I think you can simply create a
> recovery.conf in the old master's data directory to turn it into a standby
> server, and restart. Am I missing something?

Failover always increments the timeline ID of the old standby (i.e.,
new master).
Can that procedure work around the gap of the timeline ID between servers?


Fujii Masao
NTT Open Source Software Center

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2010-05-29 08:13:28
Subject: Re: pg_trgm
Previous:From: Bruce MomjianDate: 2010-05-29 02:32:26
Subject: Re: small exclusion constraints patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group