On Fri, Sep 07, 2007 at 02:10:32PM -0700, david@lang.hm wrote:
> >3. Easy to set up "warm standby" functionality. (Then again, if the
> >postgres server fails miserably, it's likely to be due to a disk
> >crash).
>
> and if postgres dies for some other reason the image on disk needs repair,
> unless you script stopping postgres when the SAN does it's snapshots,
> those snapshots are not going to be that good. the problems are useually
> repairable, but that makes starting your warm spare harder.
Uh, the "image" you get from a PITR backup "needs repair" too. There's
absolutely nothing wrong with using a SAN or filesystem snapshot as a
backup mechanism, as long as it's a true snapshot, and it includes *all*
PostgreSQL data (everything under $PGDATA as well as all tablespaces).
Also, to reply to someone else's email... there is one big reason to use
a SAN over direct storage: you can do HA that results in 0 data loss.
Good SANs are engineered to be highly redundant, with multiple
controllers, PSUs, etc, so that the odds of losing the SAN itself are
very, very low. The same isn't true with DAS.
But unless you need that kind of HA recovery, I'd tend to stay away from
SANs.
BTW, if you need *serious* bandwidth, look at things like Sun's
"thumper" (I know there's at least one other company that makes
something similar). 40-48 drives in a single 4U chassis == lots of
throughput.
Finally, if you do get a SAN, make sure and benchmark it. I've seen more
than one case of a SAN that wasn't getting anywhere near the performance
it should be, even with a simple dd test.
--
Decibel!, aka Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
