Skip site navigation (1) Skip section navigation (2)

Re: streaming AND file-based log-shipping?

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Ray Stell <stellr(at)cns(dot)vt(dot)edu>
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: streaming AND file-based log-shipping?
Date: 2011-04-15 07:52:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Fri, Apr 15, 2011 at 2:25 AM, Ray Stell <stellr(at)cns(dot)vt(dot)edu> wrote:

> The cookbook text says, log shipping "is mostly superseded by streaming
> replication in 9.0, though is still useful as part of a comprehensive
> backup strategy."  The implication is that the WAL archive might be
> needed for recovery in some cases:

Useful, not needed.

> 1. Under what circumstances might the WAL archive come into play in recovery?

If a WAL file is damaged, or if you wish to keep archived files for
longer than they are strictly required to make replication work.

> 2. If the streaming rep fails for some reason will the standby begin
>   recovery from the WAL archive, assuming the WAL can still be shipped?


> 3. What query or command set can be used to tell if file-based recovery is
>   configured correctly if streaming replication is active?
> I've configured both (I think), but it isn't clear to me whether
> the file-based part will function.  I guess I could bust the stream somehow
> and see what happens, but I can't find this idea documented.

Agreed, its slightly harder to test that its all working. But any
action you take that only works if something broke, can only really be
tested by deliberately breaking something. Break it, but on a test

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-admin by date

Next:From: Ray StellDate: 2011-04-15 13:09:51
Subject: Re: streaming AND file-based log-shipping?
Previous:From: Ray StellDate: 2011-04-15 01:25:00
Subject: streaming AND file-based log-shipping?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group