On Fri, Sep 07, 2007 at 02:10:32PM -0700, david@xxxxxxx 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@xxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgpeYCM9C9lnF.pgp
Description: PGP signature
