Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby
Date
Msg-id 3f0b79eb0907082308l11530a02j7de7866b008c6c85@mail.gmail.com
Whole thread Raw
In response to Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby
List pgsql-hackers
Hi,

On Wed, Jul 8, 2009 at 10:59 PM, Kevin
Grittner<Kevin.Grittner@wicourts.gov> wrote:
> Dimitri Fontaine <dfontaine@hi-media.com> wrote:
>
>>  4. sync: slave is no more lagging, it's applying the stream as it
>>     gets it, either as part of the master transaction or not
>>     depending on the GUC settings
>
> I think the interesting bit is when you're at this point and the
> connection between the master and slave goes down for a couple days.
> How do you handle that?

In the current design of synch rep, you have only to restart the standby
after repairing the network. The startup process of the standby would
restart an archive recovery from the last restart point, and request the
missing file from the primary if it's found. On the other hand, WAL
streaming would start from the current XLOG position of the primary,
which is performed by walsender and walreceiver.

If the file required for the archive recovery has gone from the primary
(pg_xlog and archive) during a couple of days, and now exists only in
a separate archive server, the archive recovery by the standby would
fail. In this case, you need to copy the missing files from the archive
server to the standby before restarting the standby. Otherwise you
need to make a new base backup of the primary, and start the setup
of the standby from the beginning.

Regards,

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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: multi-threaded pgbench
Next
From: Robert Haas
Date:
Subject: Re: *_collapse_limit, geqo_threshold