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
Re: [PERFORMANCE] Buying hardware Re: [PERFORMANCE] Buying hardware Re: [PERFORMANCE] Buying hardware |
Список | 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 по дате отправления: