it turns out that there is a simple answer.
first the sync guarantee: the client will see the effect of all
operations that happened before the sync started.
to make that guarantee we just need to make sure that the follower that
the client is connected to has all transactions that were in flight when
the sync was received.
as a side note let me point out that if you do a write, even if it
fails, you will get the same guarantee as the sync, but it will be
heavier weight because the write result will get pushed through the
atomic broadcast.
to implement sync, the follower forwards the sync to the leader. the
processing pipeline at the follower will delay any requests after the
sync until the leader replies to the sync. when the leader get sync
there are two things that can happen:
1) there aren't any outstanding transactions: the leader queues a sync
reply to the follower. it will get queued behind any pending operations
that were previously sent to the follower.
2) there are outstanding transactions: leader notes the zxid of the last
outstanding transaction and installs a trigger to queue the sync reply
when that zxid gets committed.
because everything is processed in order once a follower processes a
sync reply that follower will have processed all operations started
before the sync. note that the implementation has a stronger guarantee
than needed because it covers all operations started at the leader
before the sync. however, it is hard to reason about "started before"
since the leader determines the ordering.
ok, that was a rather long simple answer :)
ben
On 12/20/2010 11:22 AM, Fournier, Camille F. [Tech] wrote:
Hi everyone,
A simple question with a possibly not simple answer:
For transactions that happen and are committed on the leader/in the cluster
(given a cluster with quorum already) during the time in which a new follower
is being synced (sending diffs, sync, etc), what mechanism is it that ensure
that those transactions also make it to the follower that was syncing at that
time?
Thanks,
Camille
