Message-ID: <4D4A0C41.9020203@postnewspapers.com.au>
Date: Thu, 03 Feb 2011 10:00:33 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: Dan Birken <birken@gmail.com>
CC: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Which RAID Controllers to pick/avoid?
References: <AANLkTimyRh1ieWxpCo1ht2D1fkmL+Ca_8ABBEw6yN2WR@mail.gmail.com>
In-Reply-To: <AANLkTimyRh1ieWxpCo1ht2D1fkmL+Ca_8ABBEw6yN2WR@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/02/11 07:15, Dan Birken wrote:

> However, they can't guarantee that any particular RAID controller would
> be in stock when they are building the machine, so basically I would
> like to know if any of these cards are sufficiently better or worse than
> the others that I should either a) wait for a particular card or b)
> avoid a card.

I don't know the Adaptec parts above (I avoid them these days) but AFAIK
the LSI is at least OK.

Whatever RAID controller you get, make sure you have a battery backup
unit (BBU) installed so you can safely enable write-back caching.
Without that, you might as well use software RAID - it'll generally be
faster (and cheaper) than HW RAID w/o a BBU.

I get great results with Linux software RAID 10 on my Pg server - but
then, I'm not loading it particularly hard. (I continually wish the `md'
driver could use a PCIe/SATA battery-backed DRAM cache, because it'd be
capable of massively outperforming most HW raid implementation if only
it could offer safe write-back caching using persistent cache.)

> Also, I am planning on replicating this box to a standby machine with
> streaming replication.  Given this, is there any reason not to use the
> write cache on the RAID controller assuming it has battery backup?  My
> though being even in a worst case scenario if the BBU fails and the
> master DB gets corrupted, the standby (not using any write cache) would
> still be ok sans a few seconds of data (assuming the replication was
> keeping up, which would be monitored).

That sounds about right. The standby would be fine, the master would be
totaled.

If you're doing write-back caching without a BBU and things go down,
it's not going to be neatly time-warped back a few seconds. Your DB will
be corrupted, possibly massively. One big advantage of write-back
caching is that it lets the controller batch and re-order writes for
higher disk throughput as well as lower latencies at the app level. The
cost of that is that you lose the safety of ordered writes to WAL then
heap; it's quite possible for physical media writes to hit the heap
before the WAL, for newer writes to hit the WAL before older writes, etc
etc. Because of the cache, the OS and Pg never see or care about the
crazily inconsistent state of the actual disk media - unless the cache
is lost, in which case you're screwed.

Assume that a BBU failure will require restoration from a backup or from
a standby server. If you can't afford that, you should operate in
write-through cache mode, possibly using synchronous commit and/or
commit delay options if you can afford a few seconds data loss on crash.

-- 
System & Network Administrator
POST Newspapers