Re: [bailey-developers] SF.net SVN: bailey: [17] trunk/src

[Ning L. <nin...@gm...>]

On Fri, Apr 4, 2008 at 7:26 PM, Doug Cutting <cu...@ap...> wrote:
>  I've been going back-and-forth in my head to try to decide how we want
>  to use Zookeeper and whether we should store the current ring there.
>  This is certainly an argument for that.  It makes for a more stateful
>  master than I'd hoped, but that might not be bad.
>
>  An extreme idea would be to make Zookeeper *be* the master.  There would
>  be no XxxToMaster protocols: instead everything would be coordinated
>  through Zookeeper files.  Letting nodes directly access Zookeeper makes
>  the master less of a bottleneck, since Zookeeper itself replicates data.

I thought only the master writes to Zookeeper. Hosts read from Zookeeper.
We should still have a light-weight master, no? Which keeps track of
the heartbeats from the hosts, detects host failures and responds
accordingly, and decides state changes (add/remove nodes) when
appropriate...


>  I don't see it yet.  Log entry numbers are per-node, and can't be
>  compared across nodes, right?
>
>  Node A syncs from B log entries 1-10.
>  Document X is added to C.
>  A and B both sync X from C.
>  B goes offline.
>  X is deleted from C.
>  A syncs X's deletion from C.
>  A expunges its logs.
>  B comes back online.
>  A tries to sync events after 10 from B.
>
>  How does A know to ignore the addition of X?

Log entry numbers are per-node. Each node remembers the
log entry numbers it has synced with its overlapping nodes.

In this example, say B synced with A to A's entry 11 and
with C to C's entry 12 (which includes adding doc X) before
it went offline. Because A expunged its log, now A's log
entry number starts from 21. B comes back online and
finds A's 21 is newer than last time B synced with it (11).
So B cannot recover but has to sync from scratch.

Does it make sense?

Ning