On Thu, Oct 7, 2010 at 10:08 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Aidan Van Dyk <aidan@highrise.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@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.