このアプリケーションは、CouchDBでフィルタリングされたレプリケーションを使用して、ユーザーデータベースとマスターデータベース間でデータを移動します。ユーザー数を増やすと、このメッセージでレプリケーションが失敗し始めます
Source and target databases out of sync. Try to increase max_dbs_open at both servers.
max_dbs_openの数を途方もなく多い数（10,000）に増やしましたが、失敗とメッセージは同じままです。明らかに他の何かが間違っています。誰かがそれが何であるか知っていますか？
結局のところ、へのメッセージincrease max_dbs_openはせいぜい部分的な答えであり、最悪の場合は誤解を招くものです。私たちの場合、問題は開いているデータベースの数ではなく、明らかに多くのレプリケーションで使用されているHTTP接続の数でした。
各レプリケーションは、を使用できますmin(worker_processes + 1, http_connections)。ここでworker_processes、は各レプリケーションに割り当てられたワーカーの数であり、はこのドキュメントでhttp_connections説明されているように各レプリケーションに割り当てられたHTTP接続の最大数です。
したがって、使用される接続の総数は次のようになります。
number of replications * min(worker_processes + 1, http_connections)
デフォルト値のworker_processesは4、デフォルト値http_connectionsは20です。レプリケーションが100の場合、レプリケーションで使用されるHTTP接続の総数は500です。別の設定はmax_connections、CouchDBサーバーが説明するように許可するHTTP接続の最大数を決定します。このドキュメントでは。デフォルトは2048です。
この場合、各ユーザーには2つのレプリケーションがあります。1つはユーザーからマスターデータベースへ、もう1つはマスターデータベースからユーザーへのレプリケーションです。したがって、この場合、デフォルト設定では、ユーザーを追加するたびに、最終的にデフォルトを吹き飛ばす10個のHTTP接続を追加していましたmax_connections。
複製は最小限であり、ユーザーからマスターへ、およびマスターからユーザーへ移動されるデータはごくわずかであるため、、、の数をダイヤルバックしworker_processes、すべてが順調http_connectionsに進んでいます。max_connections
アップデート
他のいくつかの調査結果
より多くのオープン接続を可能にするために、プロセスの上限を引き上げる必要がありました
レプリケーションの作成が速すぎると、問題も発生しました。新しいレプリケーションを作成した速さでダイヤルバックすると、問題を緩和するのにも役立ちました。ymmv。
私の場合、このエラーは、ターゲットデータベースによって返される「instanceStartTime」GET /{targetDB}/が無効だったために発生しました。