Re: Failback with log shipping

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failback with log shipping
Date: 2010-05-28 13:25:12
Message-ID: 4BFFC438.3000101@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28/05/10 16:11, Dimitri Fontaine wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> 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?
>
> Would that mean that a controlled restart of the old master so that the
> recovery stops before applying the logs that were not shipped to the
> slave would put it in the same situation?

Not shipped before the first failover you mean? No, if any WAL records
were created in the old master that were not shipped to the standby
before failover, the corresponding changes to the data files might've
been flushed to disk already, and you can't undo those by not replaying
the WAL record on restart.

> How easy is it to script that? It seems all we need is the current XID
> of the slave at the end of recovery. It should be in the log, maybe it's
> easy enough to expose it at the SQL level…

XID doesn't help at all, LSN more likely, but I feel that I don't fully
understand what you're saying.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-28 13:26:56 Re: functional call named notation clashes with SQL feature
Previous Message Dimitri Fontaine 2010-05-28 13:11:02 Re: Failback with log shipping