Riak should manage backend lock files. #535
Comments
This was referenced Apr 16, 2014
andytill
added a commit
to andytill/bitcask
that referenced
this issue
Feb 9, 2018
…le creation Previous to this change, the OS pid was used to lock the bitcask database and prevent two bitcask instances performing write operations at the same time. However, if bitcask is not able to clean up the write locks because of a hard shutdown and another process takes that the pid in written to the lock file, bitcask is not able to take the lock even though it is the only running instance. This change uses the flock system call to obtain exclusive write access to the file across OS processes, as long as the other processes use flock to obtain the lock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There have been a couple of issues on bitcask and I think at least one on leveldb where stale lock files keep the system or particular vnodes from starting up. There've been repeated requests (basho/bitcask#99, basho/bitcask#163) to manage this at the backend level, but IMO, that's the wrong place to handle it, since there are various corner cases that the backend really shouldn't be responsible for detecting. I lay out some of my thinking here:
basho/bitcask#99 (comment)
The ideal thing in my mind is to have riak at the top/service level guarantee uniqueness, and then to extend the backend API to have a
cleanup_lockscall when riak/some other containing application has determined that it's totally safe to do so.This was kind of a distant corner case before, but as containerization gets more common, we're seeing this more and more, and that trend looks only to increase, so best to deal with it soon.
cc @bsparrow435 @joecaswell
The text was updated successfully, but these errors were encountered: