I'm also doing some tests today and indeed , like Daniel mentioned, it appears that I might be better off not doing anything in the pgpool_recovery_pitr script and just use the recovery command to rsync the WAL files over during recovery. That ,of course, having the trigger file created in the beginning of stage 1. I also removed the compression flag from rsync which also helps on speeding things up.
I'm still trying to compare the times using both types of scripts but it's kind of hard since there are several types of scenarios and several things that could impact the results which is out of pgpool control. Marcelo PostgreSQL DBA Linux/Solaris System Administrator http://www.zeroaccess.org On Dec 16, 2008, at 2:02 AM, Tatsuo Ishii wrote: >> These have been tested under PostgreSQL 8.3.X versions >> I have also tested these under stable version of pgpool and also the >> latest CVS version >> I'm sure there are things that can be improved/changed so feel free >> to >> share that. > > Thanks. Small issues I saw in your script so far: > > 1) In copy-base-backup, you touch backup_in_progress file right after > pg_stop_backup() executed to start actual WAL archiving. I think > this is too late since while doing the base backup (rsync), WAL > segment files might be generated if there's enough updation to the > database. You need to start WAL archiving *before* doing base > backup. > > 2) In pgpool_recovery_pitr, you do base backup again. I think this is > not neccessary if you sends WAL segment files to the recovery > target node generated before statge two starts and will greatly > reduce the duration of state two. > -- > Tatsuo Ishii > SRA OSS, Inc. Japan _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
