¿Cómo se comporta la replicación de CouchDB con servidores fallidos/recuperados?

Question

cuenta la situación siguiente: casos

3 EC2 ubicadas en:

• EE.UU.-WEST
• Irlanda
• Tokio

Cada instancia es un servidor dedicado CouchDB. Cada servidor CouchDB está configurado para ejecutar la replicación continua con cualquier otro servidor (bidireccional).

Supongamos ahora que el servidor de Irlanda se desconecta debido a una interrupción de AWS. Los servidores US-WEST y Tokyo CouchDB volverán a intentar X veces y luego fallarán la replicación con ese servidor (¿es correcto?)

Digamos que pasan 6 horas y AWS vuelve a conectar la región y el servidor vuelve arriba - asumo EE.UU.-oeste y Tokio ignorarán el servidor en Irlanda hasta los irlandeses CouchDB servidor re-inicia la sincronización bidireccional con dos de ellos, al estilo de:

irlandeses CouchDB _replicator Pseudo-Ajustes

• replicate [fuente = local anfitrión, target = us-oeste]
• replicación [fuente = us-oeste, target = localhost]
• replicación [fuente = localhost, target = tokyo]
• replicación [fuente = tokyo, target = localhost]

Q1: ¿Es correcto mi entendimiento de la falla/recuperación de replicación de Couch?

Q2: ¿Qué ocurre si falla la red una hora más tarde (específicamente: no hay ningún reinicio del servidor obligando al DB a reiniciarse al iniciar), ¿cómo reaccionan las respectivas instancias de CouchDB? Imagino que us-west y tokyo se olvidarán de Irlanda, pero ¿volverá Irlanda a hablar de nuevo con esos dos servidores nuevamente, reiniciando la replicación bidireccional continua?

Estoy especialmente interesado en la recuperación de fallas en el entorno EC2, por lo que si hay un detalle específico de ese entorno que he omitido, házmelo saber.

Gracias!

Answer 1

Antes de 1.1, una tarea de replicación no es persistente, incluso una continua. En el caso de una desconexión, hay un intento limitado de reintentar, pero finalmente se detendrá. Cuando se reanude la conectividad, deberá iniciar la replicación nuevamente. Como la replicación es idempotente (iniciar la misma tarea de duplicación es lo mismo que iniciarla una vez), puede agregar un cronjob para iniciarlo cada minuto (o cualquier intervalo que le parezca sensato). Si la tarea ya se está ejecutando, el intento devuelve éxito (pero no inicia otra replicación).

En 1.1, puede crear tareas de replicación persistentes creando un documento en la base de datos _replicator especial. CouchDB lo intentará de nuevo si se bloquea o la conexión se interrumpe. NOTA: 1.1.0 finalmente se da por vencido, en la próxima versión (1.1.1) permitimos reintentos infinitos.

Como CouchDB está diseñado desde cero para admitir la replicación multimaestro, no se sorprenderá al saber que maneja muy bien las interrupciones de la conectividad. Los cambios que ocurrieron durante la interrupción se encuentran y replican rápidamente.