----- Original Message -----
From: "Scott Marlowe" <smarlowe@xxxxxxxxxxxxxxxxx>
To: "Ted Byers" <r.ted.byers@xxxxxxxxxx>
Cc: "Merlin Moncure" <mmoncure@xxxxxxxxx>; "Janning Vygen" <vygen@xxxxxx>;
"pgsql general" <pgsql-general@xxxxxxxxxxxxxx>
Sent: Wednesday, April 12, 2006 2:24 PM
Subject: Re: [GENERAL] Hardware related question: 3ware 9500S
On Wed, 2006-04-12 at 13:10, Ted Byers wrote:
> ----- Original Message -----
> From: "Merlin Moncure" <mmoncure@xxxxxxxxx>
> To: "Janning Vygen" <vygen@xxxxxx>
> Cc: <pgsql-general@xxxxxxxxxxxxxx>
> Sent: Wednesday, April 12, 2006 12:31 PM
> Subject: Re: [GENERAL] Hardware related question: 3ware 9500S
> [snip]
Why? What's wrong with raid 5? I could well be wrong (given how little
attention I have paid to hardware over the past few years because of a
focus
on developing software), but I was under the impression that of the raid
options available, raid 5 with hot swappable drives provided good data
protection and performance at a reasonably low cost. Is the problem with
the concept of raid 5, or the common implementations?
Do you have a recommendation regarding whether the raid array is built
into
the server running the RDBMS (in our case PostgreSQL), or located in a
network appliance dedicated to storing the data managed by the RDBMS? If
you were asked to design a subnet that provides the best possible
performance and protection of the data, but without gold-plating
anything,
what would you do? How much redundancy would you build in, and at what
granularity?
There have been NUMEROUS discussions of RAID-5 versus RAID 1+0 in the
perform group in the last year or two. Short version:
Interesting.
I take it that "RAID 1+0" refers to a combination of Raid 1 and RAID 0.
What about RAID 10? I am curious because RAID 10 has come out since the
last time I took a look at RAID technology. I am not sure what it actually
does differently from RAID 5.
This question of data security is becoming of increasing importance to me
professionally since I will soon have to advise the company I'm working with
regarding how best to secure the data managed by the applications I'm
developing for them. I will need overall guidelines to produce a design
that makes it virtually impossible for them to lose even on field in one
record. The data is both sensitive and vital. Fortunately, I have a few
months before we need to commit to anything. Also, fortunately, with one
exception, the applications rely on a data feed that comes in once a day
after normal working hours, so I won't have to worry about writes to the DB
other than what my script does to load the datafeed into the DB. All other
access is read only. This should make it easier to produce a strategy to
protect the data from any kind of technology failure (software or hardware).
Cost is a factor, but reliability is much much more important!
Thanks,
Ted
