Earlier quoted context omitted.
Nope, zookeeper nodes have ids that always increment and can be used for fencing, compare-and-set and more...
I was talking about consul and etcd.
So you can do fencing with consul.
71–73 of 73 posts
Earlier quoted context omitted.
Nope, zookeeper nodes have ids that always increment and can be used for fencing, compare-and-set and more...
I was talking about consul and etcd.
So you can do fencing with consul.
Earlier quoted context omitted.
Nope, zookeeper nodes have ids that always increment and can be used for fencing, compare-and-set and more...
I was talking about consul and etcd.
node.modifiedIndex appears sensible for fencing.
Interesting stuff. In all my distributed systems work so far, I've assumed that a distributed lock is a thing to avoid. I really should take another look at them, just as a tool to have at my disposal.
If you assume that your distributed lock gives you transactional guarantees that you are the only lock holder then you are making a mistake. If, however, you can tolerate small overlaps in lock holders you are fine and this helps with numerous distributed algorithms. Further, using other facilities such as fences can make it even more secure. Another feature of ZooKeeper is write-with-version. You could obtain a lock…