Date: Tue, 6 May 2008 22:37:09 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: Dennis Muhlestein <djmuhlestein@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Possible Redundancy/Performance Solution
In-Reply-To: <fvqj5j$5v5$1@news.hub.org>
Message-ID: <Pine.GSO.4.64.0805062030020.11322@westnet.com>
References: <fvq189$2ej4$1@news.hub.org>
	<Pine.GSO.4.64.0805061316340.3589@westnet.com>
	<fvq854$ocq$1@news.hub.org>
	<Pine.GSO.4.64.0805061625150.11474@westnet.com>
	<fvqj5j$5v5$1@news.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 6 May 2008, Dennis Muhlestein wrote:

> Those are good points.  So you'd go ahead and add the pgpool in front (or 
> another redundancy approach, but then use raid1,5 or perhaps 10 on each 
> server?

Right.  I don't advise using the fact that you've got some sort of 
replication going as an excuse to reduce the reliability of individual 
systems, particularly in the area of disks (unless you're really creating 
a much larger number of replicas than 2).

RAID5 can be problematic compared to other RAID setups when you are doing 
write-heavy scenarios of small blocks, and it should be avoided for 
database use.  You can find stories on this subject in the archives here 
and some of the papers at http://www.baarf.com/ go over why; "Is RAID 5 
Really a Bargain?" is the one I like best.

If you were thinking about 4 or more disks, there's a number of ways to 
distribute those:

1) RAID1+0 to make one big volume
2) RAID1 for OS/apps/etc, RAID1 for database
3) RAID1 for OS+xlog, RAID1 for database
4) RAID1 for OS+popular tables, RAID1 for rest of database

Exactly which of these splits is best depends on your application and the 
tradeoffs important to you, but any of these should improve performance 
and reliability over what you're doing now.  I personally tend to create 
two separate distinct volumes rather than using any striping here, create 
a tablespace or three right from the start, and then manage the underlying 
mapping to disk with symbolic links so I can shift the allocation around. 
That does require you have a steady hand and good nerves for when you 
screw up, so I wouldn't recommend that to everyone.

As you get more disks it gets less practical to handle things this way, 
and it becomes increasingly sensible to just make one big array out of 
them and stopping worrying about it.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD