Re: [PERFORMANCE] Buying hardware

Поиск
Список
Период
Сортировка
От Jeff
Тема Re: [PERFORMANCE] Buying hardware
Дата
Msg-id 574C28BA-7A41-4134-92E6-49282D37903E@torgo.978.org
обсуждение исходный текст
Ответ на Re: [PERFORMANCE] Buying hardware  (David Rees <drees76@gmail.com>)
Ответы Re: [PERFORMANCE] Buying hardware  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: [PERFORMANCE] Buying hardware  (Kenny Gorman <kgorman@hi5.com>)
Re: [PERFORMANCE] Buying hardware  (David Rees <drees76@gmail.com>)
Re: [PERFORMANCE] Buying hardware  (Craig Ringer <craig@postnewspapers.com.au>)
Список pgsql-performance
On Jan 26, 2009, at 2:42 PM, David Rees wrote:
>
> Lots of people have databases much, much, bigger - I'd hate to imagine
> have to restore from backup from one of those monsters.
>

If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to untar / whatever it into
place.  Our backup script basically does:

archive backup directory
pg_start_backup
rsync
pg_stop_backup

voila. I have 2 full copies of the db.  You could even expand it a bit
and after the rsync & friends have it fire up the instance and run
pg_dump against it for a pg_restore compatible dump "just in case".

It takes a long time to restore a 300GB db, even if you cheat and
parallelify some of it. 8.4 may get a  pg_restore that can load in
parallel - which will help somewhat.

--
Jeff Trout <jeff@jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/




В списке pgsql-performance по дате отправления:

Предыдущее
От: David Rees
Дата:
Сообщение: Re: [PERFORMANCE] Buying hardware
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: [PERFORMANCE] Buying hardware