From File::SharedNFSLock:
It's in production use at our site, but if it doesn't work for you, I'm not surprised! ... I use the fact that hard links are (err, appear to be) atomic ... Basic unit tests are in place for this module. However, it is not extensively tested (Patches welcome!). While the module is used on production systems here, do your own testing since it may contain hidden race conditions.
You should probably carry over these possibly quite serious caveats into your documentation.
| [reply] |
Thanks for pointing that out! I've updated the original post with the caveat.
Please note, however, that lock_write is optional, and atomic_write might work just as well for most applications.
| [reply] |
While LMDB's internal lock manager relies on pthread mutexes to control write access, and so cannot work across NFS, you can turn that off and use your own lock management instead. This is the approach we used in the LMDB driver for postfix.
http://www.postfix.org/LMDB_README.html
The OpenLDAP mailing list emails you referenced only talk about LMDB's internal locking.
-- hyc | [reply] |
| [reply] |
I'd like to point out that in large, IT-managed infrastructure, it's actually impossible to get away from NFS. Even home directories are actually hosted on NFS!
To clarify, when I say "serverless", I mean that the user of the database system need not launch any server processes to avail of NFSdb.
| [reply] |
Thanks for the condescension, but it's actually not impossible to get away from NFS. Most of my work is done with application-level clustering.
I've done NFS-hosted home directories (and in fact /etc and /usr too; also used other networked file systems like AFS for that) before. It does grant some flexibility but it is far from the only way to do things. Maybe you should look at Ceph, GlusterFS, or GFS2 if you really want shared files.
If you trust yourself to write a fully-fledged database more than the PostgreSQL folks then go right ahead. I'd personally rather let the DB folks take care of anything more complex than a simple key/value store or object store. I like to focus my efforts elsewhere in the stack where we have problems that aren't already solved. PostgreSQL can be replicated very reliably and application scaling can be accomplished a number of ways other than putting everything on one big central file store.
We actually have a home-grown distributed object store with eventual consistency and failover to the original storage server for things not yet fully replicated. It's not what we use for a database. It's used as an object store. The database (often poor little MySQL, but sometimes PostgreSQL) is used as the database, complete with replication and read/write spreading with failover.
| [reply] |