Re: [HACKERS] Warm-Standby using WAL archiving / Seperate
Ühel kenal päeval, T, 2006-07-11 kell 08:38, kirjutas Andrew Rawnsley: > Just having a standby mode that survived shutdown/startup would be a nice > start... I think that Simon Riggs did some work on this at the code sprint yesterday. > I also do the blocking-restore-command technique, which although workable, > has a bit of a house-of-cards feel to it sometimes. > -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Warm-Standby using WAL archiving / Seperate
On Mon, 2006-07-10 at 19:34 +0200, Florian G. Pflug 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. Just submitted a patch to allow restartable recovery, which addresses this concern. > Monitoring this system is hard too, since there is no easy way to detect > errors > while restoring a particular wal. What do you mean? If there is an ERROR in the WAL file, it stops. If the restore of the WAL file fails, it retries a few times before giving up. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Warm-Standby using WAL archiving / Seperate
Just having a standby mode that survived shutdown/startup would be a nice start... I also do the blocking-restore-command technique, which although workable, has a bit of a house-of-cards feel to it sometimes. On 7/10/06 5:40 PM, "Florian G. Pflug" <[EMAIL PROTECTED]> wrote: > Merlin Moncure wrote: >> On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> 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 Y& ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Warm-Standby using WAL archiving / Seperate pg_restorelog
Merlin Moncure wrote: On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Warm-Standby using WAL archiving / Seperate pg_restorelog application
On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> 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. merlin ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
