Hopefully this should only hurt availability/liveness, not cause you to loose data. ZooKeeper will not allow you to issue any more updates before having again at least 3 servers. This of course assumes that servers still have the information they previously wrote to disk after they reboot.
On Mon, Oct 21, 2013 at 4:53 PM, Thawan Kooburat <[email protected]> wrote: > (2) You can lose a committed data if have more failure than what the > quorum is configured to support (eg. losing 3 out of 5 hosts) > > -- > Thawan Kooburat > > > > > > On 10/21/13 4:48 PM, "Alexander Shraer" <[email protected]> wrote: > >>Hi, >> >>(1) Zab is an atomic broadcast protocol, it satisfies strong ordering >>properties. Check out the paper: >>http://www.stanford.edu/class/cs347/reading/zab.pdf >> >>Its used to propagate updates in the same order to all the ZooKeeper >>servers. The provided consistency in ZooKeeper is basically sequential >>consistency + >>real-time-order on writes. This is strong, although not linearizable >>(its possible that you read from a server that has stale data). >> >>If you use the sync call before a read, ZooKeeper provides >>ilnearizability for sync+read and write operations (this is true with >>certain timing assumption made in ZooKeeper for efficiency). >> >>(2) No, only a suffix of uncommitted operations can disappear. >>Operations acked by a quorum never dissappear. >> >>(3) For read operations the server responds immediately using local >>state. For writes it responds after a quorum acked the update. >> >> >>Alex >> >>On Mon, Oct 21, 2013 at 1:47 AM, 聂安 <[email protected]> wrote: >>> hi all, >>> >>> About zk, I got some questions bothered me for one week, which can be >>>described as follows: >>> >>> (1) Does zab guarantee a strong consistency? >>> >>> (2) Could those committed proposals on new-elected-followers be deleted >>>when initially synced? >>> >>> (3) When does the server in zk respond to the client? After commiting >>>the proposal? >>> >>> thank you！ >>> >>> >>> >>> >>> Regards, >>> >>> An.Nie >
