Re: Backup and Restore mechanism in Postgres
От | Brian A. Seklecki |
---|---|
Тема | Re: Backup and Restore mechanism in Postgres |
Дата | |
Msg-id | 20060124122348.W37425@arbitor.digitalfreaks.org обсуждение исходный текст |
Ответ на | Re: Backup and Restore mechanism in Postgres (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Список | pgsql-general |
On Tue, 20 Sep 2005, Lincoln Yeoh wrote: > At 10:00 AM 9/20/2005 -0400, Vivek Khera wrote: > > >> On Sep 14, 2005, at 9:45 AM, vinita bansal wrote: >> >>> I have a 4 proc. AMD Opteron machine with 32 GB RAM and ~400GB HDD Just curious what ever came of this? Also, were you reading the DB and writing the dump file from the same file system? Different partitions on the same disk? The 400GB is presumably a RAID1+0 or RAID5? If that's the case then, I would highly recommend having a separate physical drive/file system for writing backups to (from which your actual backup software should be pointed). Maybe even put it on a different channel on the same controller, or a different controller alltogether.. Obviously, the biggest thing missing from a lot of PostgreSQL documentation is practicle information for large deployments, including strategy and system design requirements. All in due-time I suppose. ~BAS > > Any reason why Postgresql would only get 2.8MB/sec for dumps or slower? > > Regards, > Link. > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
В списке pgsql-general по дате отправления: