nova-orchestration team mailing list archive
Mailing list archive
Re: Row-level db locking vs. ZooKeeper ...
Out of curiosity, what does zookeeper use for inter-node communications?
How big can it scale?
On Wed, Nov 9, 2011 at 1:35 AM, Yun Mao <yunmao@xxxxxxxxx> wrote:
> Row-level db locking is an internal mechanism for database to
> implement ACID transactions. It's not supposed to be exposed to users
> and implementation specific. For example, in MySQL you can only have
> it with InnoDB. With MyISAM you can have table-level locking only.
> There is no SQL standard that I'm aware of for you to explicitly grab
> a lock on a row, but you can use statement like "SELECT xxx FOR
> UPDATE" to block other transactions. I think Nova uses this trick to
> allocate fixed IP addresses from the pool.
> ZooKeeper is different from a database. One typical usage is to use it
> as a lock service only. That is the state does not live in ZooKeeper,
> but elsewhere. So you can grab the lock, do whatever processing and
> release the lock later without race condition. For instance you can
> spawn a VM, take snapshot, etc.. Another usage is that if the state is
> relatively small (e.g. within 1MB), you can put it inside on a
> ZooKeeper node. ZooKeeper supports atomic node update in the spirit of
> compare and swap.
> ZooKeeper also differs from a DB from a HA perspective. It is designed
> to be distributed and fault tolerant. With 2f+1 nodes running, you can
> tolerate f node failures. Databases like MySQL is designed for a
> single node. You can use DRBD to replicate to another node but once
> there is a network disconnection it's getting tricky to recover.
> On Tue, Nov 8, 2011 at 8:56 AM, Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx> wrote:
>> Hi Yun,
>> Thanks again for the pointer to ZooKeeper. I think it's a very interesting project and looks like a great way to solve the worker sync problem we face with Orchestration.
>> One thing that wasn't clear to me immediately was the benefit of using something like ZooKeeper vs doing row-level db locking (where the row is the transaction state)?
>> Perhaps you could elaborate on that a little?
> Mailing list: https://launchpad.net/~nova-orchestration
> Post to : nova-orchestration@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova-orchestration
> More help : https://help.launchpad.net/ListHelp