の違い私は現在、CouchDBのレプリケーションを探索し、max_replication_retry_countおよびコンフィギュレーションファイルの[レプリケータ]セクションでretries_per_request設定オプションの違いを把握しようとしています。のCouchDB：max_replication_retry_countとretries_per_request
基本的には、継続的にオフラインになっている可能性のある期間（数日または数週間）を考慮して、レプリケーションの試行を止めることのないリモートインスタンスに対してローカルcouchdbの連続レプリケーションを設定します。だから、私は5分程度の最大再試行間隔で無限複製をしたいと思っています。これはできますか？これを実現するにはデフォルト設定を変更する必要がありますか？
ここで私はCouchDBのメーリングリストで持っているの返信です：
我々はソファー1.6、retries_per_request コントロール属性を話している場合は、現在のレプリケーションが 読むために何をするつもりされた試行回数_changesは諦める前に飼います。 max_replication_retry_countは、レプリケーションマネージャによってレプリケーションジョブ全体が再試行される回数を制御します。 この属性を「無限」に設定すると、レプリケート のマネージャは決してあきらめないようにする必要があります。
これらの試行の間隔は設定できないと思います。 私が理解する限り、それは の再試行の間に2.5秒から開始し、次に10分に達するまで2倍になります。これは ハード上限です。
拡張答え：
答えはあなたが1.1/2.0 リリースや、現在のマスターを使用しているかによって多少異なります。
1.xまたは2.0リリースを使用している場合： "max_replication_retry_count = infinity"に設定すると、失敗したレプリケーションは常に再試行されます。その設定値 は、エラーが発生した場合にレプリケーションジョブ全体がどのように再開するかを制御します。 次に、 "retries_per_request"を使用して、個々の レプリケータHTTP要求のエラーを処理できます。基本的に、即時の即時 の再試行が成功する場合。 "retries_per_request"のデフォルト値は10です。 最初の失敗の後、0.25秒の待機があります。それでは、次に が失敗すると0.5倍になります。最大待ち時間は5分です。 しかし、定期的にオフラインになることが予想される場合は、 個々のリクエストをあまりに長くして再試行する価値はないかもしれません。 「retries_per_request」を6または7に減らしてください。個々のリクエストは を約10〜複製ジョブ全体 がクラッシュして再試行します。
新しいスケジュール レプリケータを持っている現在のマスター、使用している場合：設定 がなくなっていると、すべてのレプリケーションジョブは常に限り 複製文書が存在するために再試行することを、「max_replication_retry_count」に設定する必要はありませんが。しかし、 "retries_per_request"は上記と同じ と同じです。レプリケーションスケジューラは、 レプリケーションジョブが連続して失敗すると、指数バックオフも行います。最初のバックオフは30秒です。その後、 は1分、2分などに倍増します。最大バックオフ待機時間は約8時間で です。しかし、 のネットワーク接続が復旧したときに再起動する平均時間が4時間にならないようにするには、 を約5分程度にしたい場合は、 "replicator"の設定で "max_history = 8"セクション。 max_historyは、レプリケーションジョブごとに保持されている過去のイベントの履歴を制御します。連続したクラッシュの履歴が少ない場合は、バックオフの待機間隔も になります。
[レプリケータ]現在のマスタのmax_replication_retry_count =無限 retries_per_request = 6
：
[レプリケータ] max_history = 8 retries_per_request =だから1.1/2.0リリースのために、要約する