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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
