Re: Failback to old master

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: "Maeldron T(dot)" <maeldron(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Failback to old master
Date: 2014-11-13 14:13:04
Message-ID: CA+CSw_sfHC1KwwkyQ3O3uu91L=3ABqbC6umZR6Up70XDRG4K4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 13, 2014 at 10:05 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
>> In this case the
>> old master will request recovery from a point after the timeline
>> switch and the new master will reply with an error. So it is safe to
>> try re-adding a crashed master as a slave, but this might fail.
>
>
> Are you sure it's guaranteed to fail, when the master had some WAL that was
> not streamed before the crash? I'm not 100% sure about that. I thought the
> old master might continue streaming and replaying, if there just happens to
> be a record start at the same point in WAL on both timelines. I think you'll
> get an error at the next checkpoint record, because its timeline ID isn't
> what the old master expects, but it would've started up already.

It seems to me like it's guaranteed. Given slave promotion at x1 and
end of xlog on old master at x2, x1 < x2, master will request
streaming at tli1.x2, wal sender does tliSwitchPoint(tli1) to lookup
x1, finds that x1 < x2 and gives the error "requested starting point
%X/%X on timeline %u is not in this server's history". The alignment
of x2 on tli2 does not play a role here.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-13 15:04:45 Re: WAL format and API changes (9.5)
Previous Message Petr Jelinek 2014-11-13 13:41:36 Re: tracking commit timestamps