Re: recovery_target_timeline and multiple slave behavior when master fails - Mailing list pgsql-general

From Rick Pufky
Subject Re: recovery_target_timeline and multiple slave behavior when master fails
Date
Msg-id CAAaAz-K4hGb9UUO378KkoLP2FRh5nuM688c6ZZUnONb0Coe0AA@mail.gmail.com
Whole thread Raw
In response to Re: recovery_target_timeline and multiple slave behavior when master fails  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-general
Thanks for the comments. I'm not actually running with an archive directory in this configuration (archiving is disabled), however, scp'ing the new history file and the last WAL File from the new master allowed the other slave to just continue replay from where it left off.

This is expected in the SR only setup configuration case?

On Sun, Dec 18, 2011 at 9:51 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Fri, Dec 16, 2011 at 3:59 AM, Rick Pufky <rick@omniti.com> wrote:
> Any thoughts on the above snippets? Am I interpreting the documentation
> correctly? Is there any further information needed to debug this?

You need to share the archive directory between all three nodes to use that
trick.

To follow the timeline change that occurs at failover to another standby,
the standby needs to read the timeline history file. This file is created and
archived at failover by new master (i.e., another standby). This file is not
shipped via replication, so the standby needs to read it from the archive.
So you need to have the shared archive directory.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



--
Rick Pufky
OmniTI Computer Consulting Inc.
Database Administrator

pgsql-general by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Feature Request: Better handling of foreign keys in DELETE statements
Next
From: Adrian Klaver
Date:
Subject: Re: Changing Passwords as Encrypted not Clear-Text