J'explore actuellement la réplication CouchDB et essayer de comprendre la différence entre max_replication_retry_count et retries_per_request options de configuration [réplicateur] section du fichier de configuration. Fondamentalement, je veux configurer la réplication continue de couchdb local à l'instance distante qui n'arrêterait jamais les tentatives de réplication, compte tenu des périodes potentiellement continues d'être déconnecté (jours ou même semaines). Donc, je voudrais avoir des tentatives de réplication infinies avec un intervalle de réessai maximum de 5 minutes ou plus. Puis-je faire ceci? Ai-je besoin de changer la configuration par défaut pour y parvenir?CouchDB: différence entre max_replication_retry_count et retries_per_request
Répondre
Voici les réponses que j'ai à des listes de diffusion CouchDB:
Si nous parlons Couch 1.6, l'attribut retries_per_request contrôle un certain nombre de tentatives de réplication en cours va faire pour lecture _change les aliments avant d'abandonner. L'attribut max_replication_retry_count contrôle un certain nombre de tentatives que tout le travail de réplication va être réessayé par un gestionnaire de réplication. Si vous définissez cet attribut sur "infinity", le gestionnaire de réplication doit ne jamais abandonner.
Je ne pense pas que l'intervalle entre ces tentatives est configurable. En tant que autant que je comprends, il va commencer à partir de 2,5 secondes entre les tentatives et ensuite doubler jusqu'à atteindre 10 minutes, ce qui va être limite supérieure dure.
réponse prolongée:
La réponse est légèrement différente selon que vous utilisez 1.x/2.0 ou versions maître actuel.
Si vous utilisez 1.x ou version 2.0: Set « max_replication_retry_count = l'infini » il sera toujours une nouvelle tentative réplications échoué. Ce paramètre contrôle le redémarrage de l'ensemble du travail de réplication en cas d'erreur. Ensuite, "retries_per_request" peut être utilisé pour gérer les erreurs pour les demandes HTTP de réplicateurs individuelles. Fondamentalement, le cas où une tentative immédiate réussit. La valeur par défaut pour "retries_per_request" est 10. Après le premier échec, il y a une attente de 0,25 seconde. Ensuite, au prochain échec, il double à 0,5 et ainsi de suite. L'intervalle d'attente maximum est de 5 minutes. Mais si vous vous attendez à être hors ligne régulièrement, peut-être que cela ne vaut pas de réessayer des demandes individuelles trop longtemps alors réduisez le "retries_per_request" à 6 ou 7. Donc, les demandes individuelles réessayeraient un quelques fois pour environ 10 - 20 secondes, puis le Tout le travail de réplication se bloque et réessaie.
Si vous utilisez maître actuel, qui a le nouveau réplicateur ordonnancement : Pas besoin de mettre « max_replication_retry_count », que la mise en a disparu et tous les travaux de réplication aura toujours une nouvelle tentative aussi longtemps que document de réplication existe. Mais "retries_per_request" fonctionne de la même manière que ci-dessus.Le planificateur de réplication effectue également des interruptions exponentielles lorsque les travaux de réplication échouent consécutivement. La première interruption est de 30 secondes. Puis double à 1 minute, 2 minutes, et ainsi de suite. Délai d'attente maximale est environ 8 heures. Mais si vous ne voulez pas attendre 4 heures en moyenne pour la réplication pour redémarrer lorsque la connectivité réseau est restaurée, et veulent environ 5 minutes, définissez "max_history = 8" dans la configuration "réplicateur" section. max_history contrôle la quantité d'historique des événements passés enregistrés pour chaque travail de réplication . S'il y a moins de antécédents de plantages consécutifs, cet intervalle d'attente de repli sera également plus court.
Donc, pour résumer, pour 1.x/2.0 rejets:
[réplicateur] max_replication_retry_count = infini retries_per_request = 6
pour le modèle actuel:
[réplicateur] max_history = 8 = retries_per_request 6