Re: Failback to old master

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: Failback to old master
Дата
Msg-id CA+CSw_sfHC1KwwkyQ3O3uu91L=3ABqbC6umZR6Up70XDRG4K4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failback to old master  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On Thu, Nov 13, 2014 at 10:05 AM, Heikki Linnakangas
<hlinnakangas@vmware.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: tracking commit timestamps
Следующее
От: Andres Freund
Дата:
Сообщение: Re: WAL format and API changes (9.5)