That is one of the great virtues in working with ZK... in the event of a
server failure, you get behavior as good as can be expected.
There are several failure scenarios:
a) a (small) fraction of the ZK servers fail or are cut off, but a quorum
persists
b) a (large) fraction of the ZK servers fa
kinds of dirty
data.
2010-03-31
Will
发件人: Ted Dunning
发送时间: 2010-03-30 15:39
主 题: Re: Re: Re: How to ensure trasaction create-and-update
收件人: zookeeper-user@hadoop.apache.org
As I mentioned, you can keep state in the disk as an echo of the diskPair.
If you don't mind a small d
As I mentioned, you can keep state in the disk as an echo of the diskPair.
If you don't mind a small delay after constructing the pair, then you can
just rely on the copy in the disk structure and never refer to the version
in the diskPair.
The other transitions that you describe can easily be imp
change the state to DUMPING, begin to copy data from the other disk of
the pair, when data ready, update state to ONLINE to serve clients.
2010-03-30
Will
发件人: Ted Dunning
发送时间: 2010-03-30 13:51
主 题: Re: Re: How to ensure trasaction create-and-update
收件人: zookeeper-user@hadoop.apache.org
Do the DISK objects contain a reference to a DISK-PAIR? What about the
reverse?
Can DISK's be in more than one DISK-PAIR?
I will assume some answers to these so I can give a design.
Suppose that DISK's just contain other information, but do not refer to
DISK-PAIR's and and can only exist in a s
Thanks for your quick reply, Ted.
we are implementing a distributed system, using zookeeper for master metedata
persistence. There's DISK object and DISK-PAIR object. when creating a
DISK-PAIR, we need to first create a znode indicating DISK-PAIR object and
updating the corresponding two DISK's
