Re: Contemplating SSD Hardware RAID - Mailing list pgsql-performance

From Greg Smith
Subject Re: Contemplating SSD Hardware RAID
Date
Msg-id 4E003B44.9090005@2ndQuadrant.com
Whole thread Raw
In response to Contemplating SSD Hardware RAID  (Dan Harris <fbsd@drivefaster.net>)
Responses Re: Contemplating SSD Hardware RAID
List pgsql-performance
On 06/20/2011 11:54 PM, Dan Harris wrote:
> I understand that the majority of consumer grade SSD drives lack the
> required capacitor to complete a write on a sudden power loss.  But,
> what about pairing up with a hardware controller with BBU write
> cache?  Can the write cache be disabled at the drive and result in a
> safe setup?

Sometimes, but not always, and you'll be playing a risky and
unpredictable game to try it.  See
http://wiki.postgresql.org/wiki/Reliable_Writes for some anecdotes.  And
even if the reliability works out, you'll kill the expected longevity
and performance of the drive.

> I'm exploring the combination of an Areca 1880ix-12 controller with 6x
> OCZ Vertex 3 V3LT-25SAT3 2.5" 240GB SATA III drives in RAID-10.  Has
> anyone tried this combination?  What nasty surprise am I overlooking
> here?

You can expect database corruption the first time something unexpected
interrupts the power to the server.  That's nasty, but it's not
surprising--that's well documented as what happens when you run
PostreSQL on hardware with this feature set.  You have to get a Vertex 3
Pro to get one of the reliable 3rd gen designs from them with a
supercap.  (I don't think those are even out yet though)  We've had
reports here of the earlier Vertex 2 Pro being fully stress tested and
working out well.  I wouldn't even bother with a regular Vertex 3,
because I don't see any reason to believe it could be reliable for
database use, just like the Vertex 2 failed to work in that role.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: sequential scan unduly favored over text search gin index
Next
From: Vladimir Kulev
Date:
Subject: Re: Inoptimal query plan for max() and multicolumn index