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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
