SQLite与OpenAFS锁定兼容吗？

Question

我想在许多联网计算机上有许多进程同时通过OpenAFS 1.4.12.1访问同一个SQLite数据库.写入很少,因此SQLite的单写设计应该不是问题.

我想知道这是否可行.我无法找到两个关键信息:

在SQLite的文件指出,"SQLite的使用POSIX咨询锁来实现锁定在Unix".它还警告说"你最好的防御就是不要将SQLite用于网络文件系统上的文件".但是,它似乎没有指定SQLite是仅使用整个文件锁定,还是它还使用字节范围锁定.

我也很难找到OpenAFS 1.4.12.1支持哪种类型的锁定.不幸的是,1998年的这个非正式来源是我能找到的最好的资料来源.那时,支持整个文件锁定但不支持字节范围锁定.

官方文档只显示这个页面,尽管它的友好标题实际上没有说明最新的OpenAFS是否支持POSIX字节范围建议锁定.

编辑:这有可能吗？如果是这样,是否需要任何编译时SQLite标志？

Answer 1

我已经使用SQLite已经有一段时间了,并且已经有了处理一些锁定问题的"财富".我很确定SQLite默认在Unix文件系统上使用字节范围锁.

更确切地说,它包含一些替代锁定方法的代码(例如,使用flock()和dotlock样式的整个文件锁).使用该SQLITE_ENABLE_LOCKING_STYLE选项进行编译时,它会尝试自动检测底层文件系统的正确锁定方法.

自动检测代码包含一些硬编码的情况(例如"ufs","nfs"和"smbfs"),其中没有一个是AFS.如果没有硬编码的大小写匹配,SQLite会尝试使用获取文件的字节范围锁定fcntl().然后假设如果fcntl()调用成功,则可以使用字节范围锁.

这里是哪里来的OpenAFS在做的事情有趣.显然([1],[2],[3])OpenAFS 对于用户空间应用程序有关字节范围锁定的悠久历史.从openafs-1.4.14源代码:

/* next line makes byte range locks always succeed,
 * even when they should block */
if (af->l_whence != 0 || af->l_start != 0 || af->l_len != 0) {
    DoLockWarning();
    afs_PutFakeStat(&fakestate);
    return 0;
}

一句话:哎哟!

它允许字节范围锁无论如何都能成功.在Linux上,可以想象更糟糕的是:它使用内核基础结构在同一系统的进程之间提供字节范围锁.这意味着应用程序不能只是分叉一个新进程并测试锁定机制 - 字节范围锁似乎工作正常,同时失败可怕地保护文件免受远程进程的影响.

简而言之:您无法使用OpenAFS可靠地使用未修改的SQLite.大多数其他网络文件系统也存在问题,因此建议完全避免使用网络文件系统.

一些可能的解决方法没有特定的顺序:

• 使用适当的DBMS,例如PostgreSQL.如果可以做到这一点,从长远来看,你会更好.

• 如果一个成熟的DBMS过度使用,请为您的应用程序实现自己的服务器.

• flock()在OpenAFS上将SQLite源代码修改为默认值.我不确定这是否会正常工作,因为OpenAFS有很长的历史记录([1],[2])即使是普通的锁定问题flock(),但在测试之前你不会知道.

• 使用OpenAFS用户空间实现您自己的OpenAFS VFS for SQLite,而不是通过内核.

• 试试你的运气与另一个网络文件系统.

无论您做什么,如果以任何方式涉及SQLite3和共享数据库文件,您都必须执行大量测试.

编辑:

一位意见提供者建议使用dotlock文件机制.我没有太多深入研究OpenAFS源代码,但乍一看它似乎支持open(O_CREAT|O_EXCL)创建SQLite使用的dotlock文件的方法.如果它按预期工作,那么如果强制它使用dotlock方法,则SQLite可能确实可用于OpenAFS.

也就是说,dotlocks足以解决常规本地文件系统的问题,而不会将网络文件系统的复杂性引入混合中 - 这就是为什么我首先没有提出它的原因.