From: | Hannes Dorbath <light(at)theendofthetunnel(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org pgsql-performance(at)postgresql(dot)org |
Subject: | Arguments Pro/Contra Software Raid |
Date: | 2006-05-09 09:16:45 |
Message-ID: | e3pmkc$12mk$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Hi,
I've just had some discussion with colleagues regarding the usage of
hardware or software raid 1/10 for our linux based database servers.
I myself can't see much reason to spend $500 on high end controller
cards for a simple Raid 1.
Any arguments pro or contra would be desirable.
From my experience and what I've read here:
+ Hardware Raids might be a bit easier to manage, if you never spend a
few hours to learn Software Raid Tools.
+ There are situations in which Software Raids are faster, as CPU power
has advanced dramatically in the last years and even high end controller
cards cannot keep up with that.
+ Using SATA drives is always a bit of risk, as some drives are lying
about whether they are caching or not.
+ Using hardware controllers, the array becomes locked to a particular
vendor. You can't switch controller vendors as the array meta
information is stored proprietary. In case the Raid is broken to a level
the controller can't recover automatically this might complicate manual
recovery by specialists.
+ Even battery backed controllers can't guarantee that data written to
the drives is consistent after a power outage, neither that the drive
does not corrupt something during the involuntary shutdown / power
irregularities. (This is theoretical as any server will be UPS backed)
--
Regards,
Hannes Dorbath
From | Date | Subject | |
---|---|---|---|
Next Message | Chun Yit(Chronos) | 2006-05-09 09:42:11 | Re: catalog is missing 16 attribute(s) for relid 8202590 |
Previous Message | David Goodenough | 2006-05-09 09:12:41 | Is anyone using ha-jdbc with the <distributable> tag |
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2006-05-09 09:33:42 | Re: Big IN() clauses etc : feature proposal |
Previous Message | Christian Kratzer | 2006-05-09 09:01:00 | Re: Big IN() clauses etc : feature proposal |