Re: Configuring synchronous replication

On Fri, Sep 24, 2010 at 7:47 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Fri, 2010-09-24 at 14:12 +0300, Heikki Linnakangas wrote:
>> What I'm saying is that in a two standby situation, if
>> you're willing to continue operation as usual in the master even if
>> the standby is down, you're not doing synchronous replication.
>
> Oracle and I disagree with you on that point, but I am more interested
> in behaviour than semantics.

I *think* he meant s/two standby/two server/. That's taken from the 2
references:
*the* master
*the* slave.

In that case, if the master is committing w/ no slave connected, it
*isn't* repliation, synchronous or not. Usefull, likely, but
replication, not at that PIT.

> If you have two standbys and one is down, please explain how data loss
> has occurred.

Right, of course. But thinking he meant 2 servers (1 standby) not 3
servers (2 standby).

But even with only 2 server, if it's down and the master is up, there
isn't data loss. There's *potential* for dataloss.

> But you still need to decide how you will act. I choose pragmatism in
> that case.
>
> Others have voiced that they would like the database to shutdown or have
> all sessions hang. I personally doubt their employers would feel the
> same way. Arguing technical correctness would seem unlikely to allow a
> DBA to keep his job if they stood and watched the app become
> unavailable.

Again, it all depends on the business. Synchronous replication can
give you two things:
1) High Availability (Just answer my queries, dammit!)
2) High Durability (Don't give me an answer unless your damn well sure
it's the right one)
and its goal is to do that in the face of "catastrophic failure" (for
some level of catastrophic).

It's the trade of between:
1) The cost of delaying/refusing transactions being greater than the
potential cost of a lost transaction
2) The cost of lost transaction being greater than the cost of
delaying/refusing transactions

So there are people who want to use PostgreSQL in a situation where
they'ld much rather not "say" they have done something unless they are
sure it's safely written in 2 different systems, in 2 different
locations (and yes, the distance between those two locations will be a
trade off wrt performance, and the business will need to decide on
their risk levels).

I understand it's optimal, desireable, or even praactical for the vast
majority of cases. I don't want it to be impossible, or, if it's
decide that it will be impossible, hopefully not just because you
decided nobody ever needs it, but that its not feasible because of
code/implimentation complexitites ;-)