| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Standalone synchronous master |
| Date: | 2014-01-11 02:25:26 |
| Message-ID: | 20140111022526.GG15692@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 10, 2014 at 03:17:34PM -0800, Josh Berkus wrote:
> The purpose of sync rep is to know determinatively whether or not you
> have lost data when disaster strikes. If knowing for certain isn't
> important to you, then use async.
>
> BTW, people are using RAID1 as an analogy to 2-node sync replication.
> That's a very bad analogy, because in RAID1 you have a *single*
> controller which is capable of determining if the disks are in a failed
> state or not, and this is all happening on a single node where things
> like network outages aren't a consideration. It's really not the same
> situation at all.
>
> Also, frankly, I absolutely can't count the number of times I've had to
> rescue a customer or family member who had RAID1 but wan't monitoring
> syslog, and so one of their disks had been down for months without them
> knowning it. Heck, I've done this myself.
>
> So ... the Filesystem geeks have already been through this. Filesystem
> clustering started out with systems like DRBD, which includes an
> auto-degrade option. However, DBRD with auto-degrade is widely
> considered untrustworthy and is a significant portion of why DBRD isn't
> trusted today.
>
> >From here, clustered filesystems went in two directions: RHCS added
> layers of monitoring and management to make auto-degrade a safer option
> than it is with DRBD (and still not the default option). Scalable
> clustered filesystems added N(M) quorum commit in order to support more
> than 2 nodes. Either of these courses are reasonable for us to pursue.
>
> What's a bad idea is adding an auto-degrade option without any tools to
> manage and monitor it, which is what this patch does by my reading. If
> I'm wrong, then someone can point it out to me.
Yes, my big take-away from the discussion is that informing the admin in
a durable way is a requirement for this degraded mode. You are right
that many ignore RAID degradation warnings, but with the warnings
heeded, degraded functionality can be useful.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-01-11 02:27:37 | Re: Standalone synchronous master |
| Previous Message | Tom Lane | 2014-01-11 02:22:31 | Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb |