| 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: | Whole Thread | Raw Message | 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
| 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. |