From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: High Availability with Postgres |
Date: | 2010-06-21 19:23:00 |
Message-ID: | m2iq5ctckr.fsf@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John R Pierce <pierce(at)hogranch(dot)com> writes:
>>> Two DB servers will be using a common external storage (with raid).
>
> This is also one of the only postgres HA configurations that won't lose
> /any/ committed transactions on a failure. Most all PITR/WAL
> replication/Slony/etc configs, the standby storage runs several seconds
> behind realtime.
I'm not clear on what error case it protects against, though. Either the
data is ok and a single PostgreSQL system will restart fine, or the data
isn't and you're hosed the same with or without the second system.
What's left is hardware failure that didn't compromise the data. I
didn't see much hardware failure yet, granted, but I'm yet to see a
motherboard, some RAM or a RAID controller failing in a way that leaves
behind data you can trust.
So my question would be, what case do you handle better with a shared
external storage compared to shared nothing servers with some sort of
replication (including WAL shipping)?
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Andrus | 2010-06-21 19:32:23 | Re: How to force select to return exactly one row |
Previous Message | Martin | 2010-06-21 19:14:28 | Re: How to force select to return exactly one row |