Berkeley DB Replication, 以及 Python 开发, 以及 twistd 注意事项

BDB 从 4.0 开始，内建了 Replication 支持。它是在 "DB 环境" 里增加了若干日志文件来保存 Replication 所需要的信息，实际上 db 文件的格式没有为此做特别的变化；另外，它除了提供了隐藏同步的细节的 API 外，它还提供了在几个节点之间选举出新的 Master 的 API，这些 API 统一被称为 Base replication API。可以说 BDB 提供的是一个 HA 解决方案，完全超越了常见的 Master-Slave 模式。

在 BDB 最初的设想里，同步可能是在一个复杂、异构的网络环境（可能不仅仅是 IP 网络，或者需要用到 UDP 传输）里进行的，因此它最开始需要用户自己来编写网络传输的部分 + Base replication API 做开发。从 4.5 版本开始，它提供了一套基于 TCP 连接做同步的更高级的 API，"Replication Manager"，开发者几乎不需要做任何工作，就可以轻松构建一个复制集群。

注意当前的实现里面，Slave 节点是不可写的（它要是能自动将写请求转发给 Master 节点多好！）。写入者如何将写请求发送到新的 Master 上完全依赖开发者的实现。

如果要实现一个纯粹的 Master-Slave 环境——这样丧失了 HA 特性，但前端实现却很简单，读节点和写节点的网络地址都是固定的——就必须将 Slave 节点的 priority 统统设置为 0。

官方答复是：checkpoint 就不需要了，但只要 slave 有请求，哪怕只是读操作，就需要做死锁检查

启动 REP 环境还有一点要注意的，尤其是在 slave 节点上，因为 rep_start 是启动线程后在线程里面开始从 master 同步的。如果在 rep_start 函数后就直接 db->open，有可能同步线程里面也在 db->open 而导致死锁。一个建议是等 DB_EVENT_REP_MASTER(master上) 或 DB_EVENT_REP_STARTUPDONE(slave上) 事件后再去 db->open，不过这样做仍然有危险：假如 Master 掉了，启动 Slave 是永远也得不到 startupdone 事件的。我看有的例子是除了等 startupdone 外还设置了一个等待超时时间；或者在这里加入死锁处理循环也是可行的。

对于 replication env 来说，还有一个限制就是 db 文件必须直接放在 home_dir 或 data_dir 目录下，而不能是其子目录中...

如果环境中的 db 文件很多的话，那缺省的 Mutex 数目就可能不够用了。可能是我还不熟悉 BDB，要么就实在是它的 API 报错机制不友好，总之我的应用足足折磨了我一个多星期，才无意中发现了需要调整 mutex_set_max 才能正常工作。教训是如果 BDB 节点工作不正常，首先就要用 db_stat 看看它的各项资源使用情况。

开发 BDB REP 应用，最好用 4.7.25 或更新的版本。在我的测试里面，至少其 Replication Manager 比起 4.6 要可靠一些。

bdb 的 python 绑定现在(pybsddb 4.7.0)只有 Replication Manager 的支持。从 svn trunk 来看，4.7.1 似乎将增加 Base replication API 的绑定。

google 之发现在 twistd 里调用外部线程（比如 rep_start 这样 C 扩展里创建线程的，或直接调用 thread.start_new_thread 启动的）都必须在 reactor 运行后进行，切记切记

总结：bdb 还是挺博大精深的，我强烈预感未来会有 BDB Programmer or BDB DBA 的专门职业出现。至少现在我好像就很缺一个 BDB Programmer... 呜呜呜