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
