From: Dennis Muhlestein <djmuhlestein@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Possible Redundancy/Performance Solution
Date: Tue, 06 May 2008 12:31:01 -0600
Message-ID: <fvq854$ocq$1@news.hub.org> (raw)
In-Reply-To: <Pine.GSO.4.64.0805061316340.3589@westnet.com>
References: <fvq189$2ej4$1@news.hub.org>
<Pine.GSO.4.64.0805061316340.3589@westnet.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: djmuhlestein@gmail.com
Subject: Re: Possible Redundancy/Performance Solution
In-Reply-To: <fvq854$ocq$1@news.hub.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox