Re: Standalone synchronous master

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-10 23:38:08
Message-ID: 52D08460.9050807@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 01/10/2014 03:17 PM, Josh Berkus wrote:

>> Any continuous replication should not be a SPOF. The current behavior
>> guarantees that a two node sync cluster is a SPOF. The proposed behavior
>> removes that.
>
> Again, if that's your goal, then use async replication.

I think I have gone about this the wrong way. Async does not meet the
technical or business requirements that I have. Sync does except that it
increases the possibility of an outage. That is the requirement I am
trying to address.

>
> 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.

PostgreSQL Sync replication increases the possibility of an outage. That
is incorrect behavior.

I want sync because on the chance that the master goes down, I have as
much data as possible to fail over to. However, I can't use sync because
it increases the possibility that my business will not be able to
function on the chance that the standby goes down.

>
> 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

This we absolutely agree on.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
"In a time of universal deceit - telling the truth is a revolutionary
act.", George Orwell

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-01-11 00:06:29 Re: Disallow arrays with non-standard lower bounds
Previous Message Josh Berkus 2014-01-10 23:29:27 Re: Time to do our Triage for 9.4