Re: Warm-Standby using WAL archiving / Seperate pg_restorelog
От | Florian G. Pflug |
---|---|
Тема | Re: Warm-Standby using WAL archiving / Seperate pg_restorelog |
Дата | |
Msg-id | 44B2C93A.1070106@phlo.org обсуждение исходный текст |
Ответ на | Re: Warm-Standby using WAL archiving / Seperate pg_restorelog application ("Merlin Moncure" <mmoncure@gmail.com>) |
Ответы |
Re: Warm-Standby using WAL archiving / Seperate
|
Список | pgsql-hackers |
Merlin Moncure wrote: > On 7/10/06, Florian G. Pflug <fgp@phlo.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
В списке pgsql-hackers по дате отправления: