On Wed, 25 Jun 2008, Peter T. Breuer wrote:
You can put the log/bitmap wherever you want in software raid, including
on a battery-backed local ram disk if you feel so inclined. So there is
no intrinsic advantage to be gained there at all.
You are technically correct but this is irrelevant. There are zero
mainstream battery-backed local RAM disk setups appropriate for database
use that don't cost substantially more than the upgrade cost to just
getting a good hardware RAID controller with cache integrated and using
regular disks.
What I often do is get a hardware RAID controller, just to accelerate disk
writes, but configure it in JBOD mode and use Linux or other software RAID
on that platform.
Advantages of using software RAID, in general and in some cases even with
a hardware disk controller:
-Your CPU is inevitably faster than the one on the controller, so this can
give better performance than having RAID calcuations done on the
controller itself.
-If the RAID controllers dies, you can move everything to another machine
and know that the RAID setup will transfer. Usually hardware RAID
controllers use a formatting process such that you can't read the array
without such a controller, so you're stuck with having a replacement
controller around if you're paranoid. As long as I've got any hardware
that can read the disks, I can get a software RAID back again.
-There is a transparency to having the disks directly attached to the OS
you lose with most hardware RAID. Often with hardware RAID you lose the
ability to do things like monitor drive status and temperature without
using a special utility to read SMART and similar data.
Disadvantages:
-Maintenance like disk replacement rebuilds will be using up your main CPU
and its resources (like I/O bus bandwidth) that might be offloaded onto
the hardware RAID controller.
-It's harder to setup a redundant boot volume with software RAID that
works right with a typical PC BIOS. If you use hardware RAID it tends to
insulate you from the BIOS quirks.
-If a disk fails, I've found a full hardware RAID setup is less likely to
result in an OS crash than a software RAID is. The same transparency and
visibility into what the individual disks are doing can be a problem when
a disk goes crazy and starts spewing junk the OS has to listen to.
Hardware controllers tend to do a better job planning for that sort of
failure, and some of that is lost even by putting them into JBOD mode.
However, not all hardware RAID will have such a battery-backed-up cache,
and those that do tend to have a hefty price tag.
Whereas software raid and a firewire-attached log device does not.
A firewire-attached log device is an extremely bad idea. First off,
you're at the mercy of the firewire bridge's write guarantees, which may
or may not be sensible. It's not hard to find reports of people whose
disks were corrupted when the disk was accidentally disconnected, or of
buggy drive controller firmware causing problems. I stopped using
Firewire years ago because it seems you need to do some serious QA to
figure out which combinations are reliable and which aren't, and I don't
use external disks enough to spend that kind of time with them.
Second, there's few if any Firewire setups where the host gets to read
SMART error data from the disk. This means that you can continue to use a
flaky disk long past the point where a direct connected drive would have
been kicked out of an array for being unreliable. SMART doesn't detect
100% of drive failures in advance, but you'd be silly to setup a database
system where you don't get to take advantage of the ~50% it does catch
before you lose any data.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
