Hi,
Quoting "Greg Smith" <greg@2ndquadrant.com>:
> "Synchronous replication - guarantees "zero data loss" by the means
> of atomic write operation, i.e. write either completes on both sides
> or not at all. Write is not considered complete until
> acknowledgement by both local and remote storage."
Note that a storage acknowledge (hopefully) guarantees durability, but
it does not necessarily mean that the transactional changes are
immediately visible on a remote node. Which is what you had in your
definition.
My point is that there are at least three things that can run
synchronously or not, WRT to distributed databases:
1. conflict detection and handling (for consistency) 2. storage acknowledgement (for durability) 3. effective
applicationof changes (for visibility across nodes)
> That last part is the critical one: "acknowledgement by both local
> and remote storage" is required before you can label something truly
> synchronous replication. In implementation terms, that means you
> must have both local and slave fsync calls finish to be considered
> truly synchronous. That part is not ambiguous at all.
I personally agree 100%. (Given it implies a congruent conflict
handling *before* the disk write. Having conflicting transactional
changes on the disk wouldn't help much at recovery time).
(And yes, this means I think the effective application of changes can
be deferred. IMO the load balancer and/or the application should take
care not to send transactions from the same session to different nodes).
> "Semi-synchronous replication
..is plain non-sense to my ears. Either something is synchronous or it
is not. No half, no semi, no virtual synchrony. To have any technical
relevance, one needs to add *what* is synchronous and what not.
In that spirit I have to admit that the term 'eager' that I'm
currently using to describe Postgres-R may not be any more helpful. I
take it to mean synchrony of 1. and 2., but not 3.
Regards
Markus Wanner
