Re: Possible Redundancy/Performance Solution
От | Dennis Muhlestein |
---|---|
Тема | Re: Possible Redundancy/Performance Solution |
Дата | |
Msg-id | fvq854$ocq$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Possible Redundancy/Performance Solution (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: Possible Redundancy/Performance Solution
|
Список | pgsql-performance |
Greg Smith wrote: > On Tue, 6 May 2008, Dennis Muhlestein wrote: > > > RAID0 on two disks makes a disk failure that will wipe out the database > twice as likely. If you goal is better reliability, you want some sort > of RAID1, which you can do with two disks. That should increase read > throughput a bit (not quite double though) while keeping write > throughput about the same. I was planning on pgpool being the cushion between the raid0 failure probability and my need for redundancy. This way, I get protection against not only disks, but cpu, memory, network cards,motherboards etc. Is this not a reasonable approach? > > If you added four disks, then you could do a RAID1+0 combination which > should substantially outperform your existing setup in every respect > while also being more resiliant to drive failure. > >> Our applications are mostly read intensive. I don't think that having >> two databases on one machine, where previously we had just one, would >> add too much of an impact, especially if we use the load balance >> feature of pgpool as well as the redundancy feature. > > A lot depends on how much RAM you've got and whether it's enough to keep > the cache hit rate fairly high here. A reasonable thing to consider > here is doing a round of standard performance tuning on the servers to > make sure they're operating efficient before increasing their load. > >> Can anyone comment on any gotchas or issues we might encounter? > > Getting writes to replicate to multiple instances of the database > usefully is where all the really nasty gotchas are in this area. > Starting with that part and working your way back toward the front-end > pooling from there should crash you into the hard parts early in the > process. Thanks for the tips! Dennis
В списке pgsql-performance по дате отправления: