为什么在增加max_dbs_open之后，复制仍会因“增加max_dbs_open”而失败？

Question

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

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

我们已经这样做了，将max_dbs_open的数量增加到一个可笑的高数字（10,000），但失败和消息保持不变。显然其他事情是错误的。有谁知道它是什么？

Answer 1

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

每个复制都可以使用min(worker_processes + 1, http_connections)，其中worker_processes是分配给每个复制的工作者数量，http_connections是为每个复制分配的最大HTTP连接数，如上所述{{3} }。

所以使用的连接总数是

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

默认值worker_processes为4，默认值http_connections为20.如果有100个复制，则复制使用的HTTP连接总数为500.另一个设置为{{ 1}}，确定CouchDB服务器允许的最大HTTP连接数，如in this document所述。默认值为2048。

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

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

更新

其他一些发现

1. 有必要提高流程的ulimit，使其具有更多的开放连接

2. 过快地创建复制也会导致问题。如果我拨回了我创建新复制的速度，它也有助于缓解问题。因人而异。

Answer 2

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