Re: Warm-Standby using WAL archiving / Seperate pg_restorelog

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Postgresql-General <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Warm-Standby using WAL archiving / Seperate pg_restorelog
Date: 2006-07-10 21:40:10
Message-ID: 44B2C93A.1070106@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Merlin Moncure wrote:
> On 7/10/06, Florian G. Pflug <fgp(at)phlo(dot)org> wrote:
>> This methods seems to work, but it is neither particularly fool-proof nor
>> administrator friendly. It's not possible e.g. to reboot the slave
>> without postgres
>> abortint the recovery, and therefor processing all wals generated
>> since the last
>> backup all over again.
>>
>> Monitoring this system is hard too, since there is no easy way to
>> detect errors
>> while restoring a particular wal.
>
> what I would really like to see is to have the postmaster start up in
> a special read only mode where it could auto-restore wal files placed
> there by an external process but not generate any of its own. This
> would be a step towards a pitr based simple replication method.

I didn't dare to ask for being able to actually _access_ a wal-shipping
based slaved (in read only mode) - from how I interpret the code, it's
a _long_ way to get that working. So I figured a stand-alone executable
that just recovers _one_ archived wal would at least remove that administrative
burden that my current solution brings. And it would be easy to monitor
the slave - much easier than with any automatic pickup of wals.

greetings, Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2006-07-10 21:48:18 Re: lastval exposes information that currval does not
Previous Message Martijn van Oosterhout 2006-07-10 21:35:54 Re: CTIDs invalidations and dropping columns.