2011/8/15 Tuure Laurinolli <tuure.laurino...@portalify.com>

>
> On Aug 12, 2011, at 20:40 , Tuure Laurinolli wrote:
> >
> >> Updates will however propagate from the master to other slaves
> eventually so
> >> a write from one slave is not immediately visible on all other slaves.
> >>>> It sounds like eventual consistency from master to other slaves. if
> so, I
> >>>> am interested in finding out details about Neo4j HA member nodes
> voting
> >>>> quorum & arbitrater setup (assuming using zookeeper)
> >
> > Looking at the code, it seems that the transaction is first prepare()'d
> on the slave, then the prepared log shipped to the master, applied and
> committed there, and the master txid shipped back and used to commit the
> transaction on slave. However, the locks seem to be held (both on slave and
> master) until the slave finishes committing or rolling back, so no
> visibility problems should occur.
>
> Further, the Transaction that MasterClient/MasterServer/MasterImpl creates
> on server-side is apparently only ever really used to hold locks. It is
> always rolled back (finishTransaction() in MasterImpl). This leads me to
> wonder if the following scenario is possible:
>
>       - Slave A replicates T to master, master commits it and gets
>         ready to return txnId, client X reads it from master, master
>         crashes
>         - Is it guaranteed that slave A commits the txn locally
>           before a new master is elected (since a new master elected
>           at this point won't have T, and thus client X would have
>           read an update that never completed successfully
>
> Clearly slave A cannot commit the transaction, and its client gets some
> sort of error. Also, since master crashed, a new master will be elected and
> the transaction will never have existed in the new cluster. Yet client X
> managed to read the result, which will be wrong. Also, in this case, when
> master is restarted, can it rejoin the cluster, since its state has diverged
> from that of the cluster?
>
> If a machine starts up and sees that it has diverged from the cluster
(represented by the current master) it will ask the master for a fresh
database and start from there... keeping the diverged db around in another
folder.

>
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to