8

我们的应用程序使用 CouchDB 过滤复制在用户数据库和主数据库之间移动数据。随着我们增加用户数量，复制开始失败并显示此消息

Source and target databases out of sync. Try to increase max_dbs_open at both servers.

我们已经做到了，将 max_dbs_open 的数量增加到一个高得离谱的数字（10,000），但故障和消息保持不变。显然还有其他问题。有谁知道它是什么？

4

2 回答 2

12

事实证明，发送的消息increase max_dbs_open充其量只是部分答案，最坏的情况是具有误导性。在我们的例子中，问题不在于打开的数据库数量，而在于我们的许多复制使用的 HTTP 连接数量。

每个复制可以使用min(worker_processes + 1, http_connections)whereworker_processes是分配给每个复制的工作人员的数量，并且http_connections是分配给每个复制的最大 HTTP 连接数，如本文档中所述。

所以使用的连接总数是

number of replications * min(worker_processes + 1, http_connections)

的默认值为worker_processes4，默认值为http_connections20。如果有 100 个复制，则复制使用的 HTTP 连接总数为 500。另一个设置 ，max_connections确定 CouchDB 服务器将允许的最大 HTTP 连接数，如所述在这份文件中。默认值为 2048。

在我们的例子中，每个用户都有两个复制——一个从用户到主数据库，另一个从主数据库到用户。因此，在我们的例子中，使用默认设置，每次我们添加一个用户时，我们都会添加额外的 10 个 HTTP 连接，最终会破坏默认设置max_connections。

由于我们的复制很少，并且只有少量数据从用户移动到主服务器，然后从主服务器移动到用户，我们拨回了worker_processes, http_connections, 增加的数量max_connections，一切都很好。

更新

其他一些发现

  1. 有必要提高进程的 ulimit 以允许它有更多打开的连接

  2. 创建复制太快也会导致问题。如果我回拨创建新复制的速度，它也有助于缓解问题。ymmv。

于 2012-11-16T13:09:05.377 回答
0

对我来说，产生这个错误是因为目标数据库返回的“instanceStartTime”GET /{targetDB}/无效。

于 2016-02-10T21:51:24.407 回答