couchDB: checkpoint_commit_failure

Question

J'ai un serveur couchDB fonctionnant sur une instance d'amazon ec2. C'est le stock 1.2.0, à partir d'un tr/min.

J'ai également plusieurs appareils android fonctionnant couchbase-mobile-2.0.

Ces périphériques lancent une réplication push-pull continue à partir du serveur. Tous ces dispositifs devraient être finalement cohérents.

Cependant, lorsque l'un des appareils mobiles pousse un document, lorsque les autres tentatives de l'appareil mobile pour tirer ce document, je reçois l'erreur suivante sur les périphériques journal:

E/CouchDB(9896): [error] [<0.199.0>] Replication `bf69ede4416770a1fef28ffb4c4e6950+continuous` (`treatment` -> `http://portecTest:*****@50.150.250.165:5984/treatment/`) failed: {checkpoint_commit_failure,<<"Error updating the target checkpoint document: conflict">>} 

L'application est conçue est telle d'une manière que ce document ne sera pas édité par les autres appareils ou le serveur, donc ce n'est pas un conflit de révision. Par la suite, plus aucun document ne sera répliqué, poussé ou tiré, jusqu'à ce que je redémarre l'application. (la réplication continue est initialisée lorsque l'application démarre). Après le redémarrage, cela fonctionne.

Qu'est-ce que cela signifie? Des idées sur ce qui pourrait en être la cause?

Answer 1

J'ai déjà vu cela en raison d'identifiants de réplication conflictuels.

Lorsque vous configurez une réplication dans la base de données _replicator, un champ _replication_id est ajouté au document (par exemple, bf69ede4416770a1fef28ffb4c4e6950 + continu, pour votre réplication actuelle). Cela est utilisé par le processus de réplication lui-même pour suivre le processus d'une réplication en gérant un document à http://server:5984/dbname/_local/replication-id aux deux extrémités de la réplication et en enregistrant des éléments comme le dernier numéro de séquence vu. Ceci est également utilisé pour repérer si vous avez deux réplications configurées pour faire la même chose, car l'identifiant est généré uniquement à partir des paramètres, donc deux réplications avec la même cible et la même source, et aucune autre option, auront le même id. Je ne suis pas totalement sûr de la façon dont le replication_id est généré (peut-être y a-t-il un germe quelque part?) Mais j'ai certainement eu des problèmes auparavant où il était généré de manière identique sur toutes les machines impliquées documents de réplication comme {source:localDb, target:remoteServer:5984/remoteDb}), alors ils ont tous ensuite essayé d'utiliser le même document db/_local/id, puis ont jeté un grand nombre de conflits, car ils changeaient tous le même document sur le serveur distant simultanément.

Vous pouvez vérifier si cela est le problème en comparant les champs _replication_id sur les deux appareils mobiles et en vérifiant s'ils sont identiques.

J'ai corrigé cela en incluant l'adresse de la machine locale dans la source, de sorte que chaque identifiant était différent, et les conflits ont disparu. Cela peut ne pas être pratique pour vous avec les appareils mobiles, à moins que vous ne puissiez obtenir une adresse locale fonctionnant de manière cohérente sur chaque mobile (un nom d'hôte généré?). Je n'ai trouvé aucun moyen de définir manuellement le replication_id.

Si tel est le problème, la solution consiste essentiellement à rendre chaque document de réplication unique des autres d'une manière ou d'une autre. Pourriez-vous nommer les différentes bases de données sur chaque appareil mobile d'une manière ou d'une autre?