Wenn wir reden Couch 1.6, das Attribut retries_per_request steuert eine Anzahl von Versuchen eine aktuelle Replikation Lese tun wird _changes Feed vor dem Aufgeben. Das Attribut max_replication_retry_count steuert eine Anzahl von Versuchen, bei denen der gesamte Replikationsjob von einem Replikationsmanager erneut versucht wird. Wenn Sie dieses Attribut auf "unendlich" setzen, sollte das Replikat Manager niemals aufgeben.
Ich glaube nicht, dass das Intervall zwischen diesen Versuchen konfigurierbar ist. Als Soweit ich verstehe, wird es von 2,5 Sekunden zwischen den Wiederholungen beginnen und dann doppelt bis 10 Minuten erreicht, die harte obere Grenze sein wird.
Die Antwort ist etwas anders, je nachdem ob Sie 1.x/2.0 Releases oder aktuelle Master verwenden.
Wenn Sie die Version 1.x oder 2.0 verwenden: Legen Sie "max_replication_retry_count = infinity" fest, so dass fehlgeschlagene Replikationen immer erneut versucht werden. Diese Einstellung steuert, wie der gesamte Replikationsauftrag neu gestartet wird, wenn ein Fehler vorliegt. Dann kann "retries_per_request" verwendet werden, um Fehler für einzelne Replikator HTTP-Anforderungen zu behandeln. Grundsätzlich der Fall, in dem eine schnelle sofortige Wiederholung erfolgreich ist. Der Standardwert für "retries_per_request" ist 10. Nach dem ersten Fehler gibt es eine Wartezeit von 0,25 Sekunden. Dann am nächsten Fehler verdoppelt sich auf 0,5 und so weiter. Das maximale Warteintervall beträgt 5 Minuten. Aber wenn Sie erwarten, offline routinemäßig zu sein, ist es vielleicht nicht versuchen, einzelne Anfragen zu lange zu wiederholen, so reduzieren Sie die "retries_per_request" auf 6 oder 7. So individuelle Anfragen würden versuchen, ein Mal für 10 - 20 Sekunden dann die Der gesamte Replikationsjob stürzt ab und versucht es erneut.
Wenn Sie aktuelle Master verwenden, die die neue Terminierung Replikator hat: Keine Notwendigkeit „max_replication_retry_count“ zu setzen, dass Einstellung und alle Jobs Replikation gegangen ist, wird solange Replikation Dokument existiert immer wieder versuchen. Aber "retries_per_request" funktioniert wie oben .Der Replikationsplaner führt auch exponentielle Backoffs durch, wenn die Replikationsjobs nacheinander fehlschlagen. Der erste Backoff ist 30 Sekunden. Dann es verdoppelt sich auf 1 Minute, 2 Minuten und so weiter. Max Backoff warte ist ca. 8 Stunden. Aber wenn Sie nicht 4 Stunden im Durchschnitt für warten die Replikation neu starten, wenn die Netzwerkkonnektivität wiederhergestellt wird, und wollen etwa 5 Minuten oder so, legen Sie "max_history = 8" in der "Replikator" Config Sektion. max_history steuert, wie viel Historie von vergangenen Ereignissen für jeden Replikationsauftrag beibehalten wird. Wenn es weniger Geschichte von aufeinander folgenden Abstürzen gibt, wird dieses Backoff-Warteintervall auch kürzer sein.
So zusammenzufassen, für 1.x/2.0 Releases:
[Replikator] max_replication_retry_count = unendlich retries_per_request = 6
Für aktuelle Master:
[Replikator] max_history = 8 retries_per_request = 6