Re: Recovery will take 10 hours

Hi Simon,

The backup with 3120 WAL files was a 2 day old base backup. We've moved
to a 1 day base backup now, but that'll still be 1600 WALs or so a day.
That will probably take 5 hours to restore I suspect. Unless we move to
2 or more base backups per day. That seems crazy though.

So how do you overlap the restore process with the retrieving of files?

Our restore command is:

restore_command = 'gunzip </wal_archive/%f.gz>%p'

If I change it to:

restore_command = 'gunzip </wal_archive/%f.gz>%p &'

to execute the restore command in the background, will that do the
trick?

But I don't think the real problem was the retrieval of the files. It
only
took maybe 1/2 a second to retrieve the file, but often took anywhere
from
5 to 30 seconds to process the file. More so on the longer end of the
scale.

Thanks,

____________________________________________________________________
Brendan Duddridge | CTO | 403-277-5591 x24 |  brendan@clickspace.com

ClickSpace Interactive Inc.
Suite L100, 239 - 10th Ave. SE
Calgary, AB  T2G 0V9

http://www.clickspace.com

On Apr 23, 2006, at 10:06 AM, Simon Riggs wrote:

> On Thu, 2006-04-20 at 13:29 -0600, Brendan Duddridge wrote:
>
>> We had a database issue today that caused us to have to restore to
>> our most recent backup. We are using PITR so we have 3120 WAL files
>> that need to be applied to the database.
>
> How often are you taking base backups?
>
>> After 45 minutes, it has restored only 230 WAL files. At this rate,
>> it's going to take about 10 hours to restore our database.
>
>> Most of the time, the server is not using very much CPU time or I/O
>> time. So I'm wondering what can be done to speed up the process?
>
> You can improve the performance of a recovery by making your restore
> command overlap retrieval of files. The recovery process waits
> while the
> restore command returns a file, so by doing an asynchronous
> lookahead of
> one file you can be gunzipping the next file while the current one is
> being processed.
>
> I'll either document this better, or build an overlap into the restore
> command processing itself, so the script doesn't need to do this.
>
> --
>   Simon Riggs
>   EnterpriseDB          http://www.enterprisedb.com/
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that
> your
>        message can get through to the mailing list cleanly
>