Re: Streaming replication failover

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Streaming replication failover
Дата
Msg-id 20120101.083832.1365874954016295836.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Streaming replication failover  (Ben Chobot <bench@silentmedia.com>)
Список pgsql-general
> I'm in the process of setting up a 9.1-based SR cluster, and I've got a question on how failover is expected to work
inthe case of multiple slaves. http://www.postgresql.org/docs/9.1/static/warm-standby-failover.html says: 
>
> "Some people choose to use a third server to provide backup for the new primary until the new standby server is
recreated,though clearly this complicates the system configuration and operational processes." 
>
> I think a third server sounds like a swell idea, but I'm unclear how a slave based on the old master can act as a
slavefor the new master. I thought that once the master switched, you'd get a new wal timeline, and any existing slaves
won'tfollow along with the new timeline. Which is really unfortunate, because it means the only way to have a slave,
immediatelyafter a failover, is to build one ASAP and hope you don't have insurmountable problems while that's going
on.For a big database, that can take a while. 
>
> Hopefully I'm missing something?

I think you can specify recovery_target_timeline to 'latest' in the
standby server's recovery.conf to solve part of your problem. The
standby will follow the new primary without restoring whole database
from the new standby as long as all logs have transferred before the
old primary went down. That means this technique can only be used in
case when the primary is scheduled down though.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

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

Предыдущее
От: Ben Chobot
Дата:
Сообщение: Streaming replication failover
Следующее
От: Alexander Farber
Дата:
Сообщение: Re: Verifying a timestamp is null or in the past