From: Dennis Muhlestein <djmuhlestein@gmail.com>
Subject: Re: Possible Redundancy/Performance Solution
Date: Tue, 06 May 2008 12:31:01 -0600
Organization: Hub.Org Networking Services
Lines: 41
Message-ID: <fvq854$ocq$1@news.hub.org>
References: <fvq189$2ej4$1@news.hub.org>
	<Pine.GSO.4.64.0805061316340.3589@westnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
In-Reply-To: <Pine.GSO.4.64.0805061316340.3589@westnet.com>
To: pgsql-performance@postgresql.org

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