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 unattended over 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 restore with 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 documentation indicates 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.ku...@enterprisedb.com
Blog:http://vibhork.blogspot.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
