Re: [HACKERS] Warm-Standby using WAL archiving / Seperate

2006-07-11 Thread Andrew Rawnsley

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

2006-07-11 Thread Simon Riggs
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

2006-07-11 Thread Hannu Krosing
Ü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 pg_restorelog application

2006-07-10 Thread Merlin Moncure

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


Re: [HACKERS] Warm-Standby using WAL archiving / Seperate pg_restorelog

2006-07-10 Thread Florian G. Pflug

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