On Feb 28, 2011, at 10:13 AM, Michael Harris wrote:
>>>
>>> Did you find anything suspicious in pg_log?
>
> We've been through it all and did not see anything we didn't expect.
>
>>> Please share recovery.conf information.
>
> We did interrupt the restore a few times. The initial recovery.conf file contained only:
>
> restore_command = 'gunzip -c /mnt/dbsbackup/pg_xlog/%f.gz > %p'
>
> Later we decided to replace the recovery command with a wrapper script that would allow us to leave the restore going
unattendedover the weekend, and complete up until the latest WAL file on the original database (which is still
running).We changed the recovery command to:
>
> restore_command = '/var/lib/pgsql/data/db_restore_dm %f %p'
>
> where the script db_restore_dm contained:
>
> #!/usr/bin/perl
>
> use strict;
>
> my ($pg_f, $pg_p) = @ARGV;
> exit 1 if $pg_f eq '00000001.history';
>
> my $xlogBackupFile = "/mnt/dbsbackup/pg_xlog/$pg_f.gz";
>
> while (! -f $xlogBackupFile and !$triggered) {
> sleep 2;
> }
>
> while (1) {
> system("gunzip -c $xlogBackupFile > $pg_p");
> last if ($? >> 8 == 0);
> sleep 2;
> }
Not sure about above wrapper function. However, if you can share some information from pg_log when you have started the
restorewith backup_label information.
Try following steps:
1. Untar all the gzipped WAL File in One Location
2. Use Following restore command:
cp <WAL Location>/%f %p
> We were concerned that shutting down / starting up while recovery is ongoing might cause some problems, but the pg
documentationindicates this should be OK and we saw no cause for concern in the pg logs.
What options have you used for shutting down?
Thanks & Regards,
Vibhor Kumar
vibhor.kumar@enterprisedb.com
Blog:http://vibhork.blogspot.com
