From: Greg Smith <gsmith@gregsmith.com>
To: Dennis Muhlestein <djmuhlestein@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Possible Redundancy/Performance Solution
Date: Tue, 6 May 2008 22:37:09 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0805062030020.11322@westnet.com> (raw)
In-Reply-To: <fvqj5j$5v5$1@news.hub.org>
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>
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
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: gsmith@gregsmith.com, djmuhlestein@gmail.com
Subject: Re: Possible Redundancy/Performance Solution
In-Reply-To: <Pine.GSO.4.64.0805062030020.11322@westnet.com>
* 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