Re: Issues with Quorum Commit

On Thu, Oct 7, 2010 at 6:32 AM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:

> Or if the standby is lagging and the master wal_keep_segments is not
> sized big enough. Is that a catastrophic loss of the standby too?

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.

I'm really confused with all this k < N scenarious I see bandied
about, because, all it really amounts to is "I only want *one*
syncronous replication, and a bunch of synchrounous replications".
And a bit of chance thrown in the mix to hope the "syncronous" one is
pretty stable, the asynchronous ones aren't *too* far behind (define
too and far at your leisure).

And then I see a lot of posturing about how to "recover" when the
"asynchronous standbys" aren't "synchronous enough" at some point...

>
> Agreed, that's a nice simple use case.
>
> Another one is to say that I want sync rep when the standby is
> available, but I don't have the budget for more. So I prefer a good
> alerting system and low-budget-no-guarantee when the standby is down,
> that's my risk evaluation.

That screems wrong in my books:

"OK, I want durability, so I always want to have 2 copies of the data,
but if we loose one, copy, I want to keep on trucking, because I don't
*really* want durability".

If you want most-of-the time mostly 2 copy durabiltiy, then really
good asynchronous replication is a really good solutions.

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.

So I'm not arguing that there shouldn't be a way to turn of
synchronous replication once it's on. Hopefully without having to
take down the cluster (pg instance type cluster) But I am pleading
that there is a way to setup PG such that synchronous replication *is*
synchronously replicating, or things stop and backup until such a time
as it is.

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.