Re: Recovery will take 10 hours

Поиск
Список
Период
Сортировка
Искать
От
Brendan Duddridge
Тема
Re: Recovery will take 10 hours
Дата
Msg-id
EDE9F59A-BB74-4185-BB9B-52942259B435@clickspace.com
Ответ на
Список
Дерево обсуждения
Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Simon Riggs <simon@2ndquadrant.com>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Simon Riggs <simon@2ndquadrant.com>
Re: Recovery will take 10 hours Markus Schaber <schabi@logix-tt.com>
Re: Recovery will take 10 hours Tom Lane <tgl@sss.pgh.pa.us>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Tom Lane <tgl@sss.pgh.pa.us>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Tom Lane <tgl@sss.pgh.pa.us>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours "Luke Lonergan" <llonergan@greenplum.com>
Re: Recovery will take 10 hours Jeff Frost <jeff@frostconsultingllc.com>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Tom Lane <tgl@sss.pgh.pa.us>
Re: Recovery will take 10 hours Brendan Duddridge <brendan@clickspace.com>
Re: Recovery will take 10 hours Jeff Frost <jeff@frostconsultingllc.com>
Thanks Tom,

We are storing only the WAL archives on the NFS volume. It must have  
been a hiccup in the NFS mount. Jeff Frost asked if we were using  
hard or soft mounts. We were using soft mounts, so that may be where  
the problem lies with the PANIC.

Is it better to use the boot volume of the database machine for  
archiving our WAL files instead of over the NFS mount? I'm sure it's  
probably not a good idea to archive to the same volume as the pg_xlog  
directory, so that's why I thought maybe using the boot drive would  
be better. We'll just have to make sure we don't fill up the drive.  
Although I know that PostgreSQL often writes to the /data directory  
that is located on the boot drive. It might not be good to start  
archiving there. Our table spaces are on a separate RAID.

If we need to restore in the future we'll just have to copy the WAL  
files from the boot drive of our database machine over the NFS to the  
restore machine.

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 20, 2006, at 5:29 PM, Tom Lane wrote:

> Brendan Duddridge  writes:
>> Oops... forgot to mention that both files that postgres said were
>> missing are in fact there:
>
> Please place the blame where it should fall: it's your archive restore
> command that's telling postgres that.
>
>> There didn't seem to be any issues with the NFS mount. Perhaps it
>> briefly disconnected and came back right away.
>
> Unstable NFS mounts are Really Bad News.  You shouldn't be expecting
> to run a stable database atop such a thing.
>
> If it's not the database but only the WAL archive that's NFS'd, it  
> might
> be possible to live with it, but you'll need to put some defenses into
> your archive restore script to cope with such events.
>
> As far as restarting goes: I think you can restart from here without
> first redoing your base-backup restore, but as previously noted it'll
> still read through the same WAL files it looked at before.  You won't
> save much except the time to redo the base restore.
>
> 			regards, tom lane
>


В списке pgsql-performance по дате отправления
От: Tom Lane
Дата:
От: Brendan Duddridge
Дата:
FAQ