From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Markus Wanner <markus(at)bluegap(dot)ch>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Issues with Quorum Commit |
Date: | 2010-10-07 14:26:10 |
Message-ID: | AANLkTim=mpXd-ZdoYN8yCsR80m+YiKMT0oiW3_gT9FcU@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 7, 2010 at 10:08 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
>> Sure, but that lagged standy is already asynchrounous, not
>> synchrounous. If it was synchronous, it would have slowed the master
>> down enough it would not be lagged.
>
> Agreed, except in the case of a joining standby.
*shrug* The joining standby is still asynchronous at this point.
It's not synchronous replication. It's just another ^k of the N
slaves serving stale data ;-)
> But you're saying it
> better than I do:
>
>> Yes, I believe you need to have a way for an admin (or
>> process/control/config) to be able to "demote" a synchronous
>> replication scenario into async (or "standalone", which is just an
>> extension of really async). But it's no longer syncronous replication
>> at that point. And if the choice is made to "keep trucking" while a
>> new standby is being brought online and available and caught up,
>> that's fine too. But during that perioud, until the slave is caught
>> up and synchrounously replicating, it's *not* synchronous replication.
>
> That's exactly my point. I think we need to handle the case and make it
> obvious that this window is a data-loss window where there's no sync rep
> ongoing, then offer users a choice of behaviour.
Again, I'm stating there is *no* choice in synchronous replication.
It's *got* to block, otherwise it's not synchronous replication. The
"choice" is if you want synchronous replication or not at that point.
And turning it off might be a good (best) choice for for most people.
I just want to make sure that:
1) There's now way to *sensibly* think it's still "synchronously replicating"
2) There is a way to enforce that the commits happening *are*
synchronously replicating.
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2010-10-07 14:29:27 | Re: On Scalability |
Previous Message | Vincenzo Romano | 2010-10-07 14:20:25 | Re: On Scalability |