¿Cómo funciona la replicación en MongoDB?
Gonzalo Ortiz JaureguizarSoftware Engineer at 8Kdata
@gortizja
Acerca de 8Kdata
Investigación y desarrollo en bases de datosDesarrolladores de ToroDB.
Una base de datos NoSQL sobre SQL.Compatible a nivel de protocolo con MongoDBDisponible con licencia AGPLv3 en Githubhttp://www.8kdata.com/torodb/
Conceptos y definiciones
ReplicaciónMantener la misma información en múltiples nodos
Single-master vs Multi-master
NodoProceso que participa en la replicación. En MongoDB los
nodos son procesos Mongod corriendo en la misma o distintas máquinas.
Replica SetConjunto de nodos que participan en la replicación
Conceptos y definiciones
Más conceptos y definiciones
Consistencia (Consistency):Que cada nodo vea la misma información en cada instante
Consistencia eventual
➢ Los nodos no ven la misma información durante una pequeña ventana de tiempo.
Disponibilidad (Availability):Cada petición tiene una respuesta indicando si ha sido
fructuosa.
Tolerancia a particiones (Partition tolerance):El sistema funciona incluso si ocurren particiones de red.
Teorema CAP
“Es imposible en un sistema distribuido garantizar, a la vez, consistencia, disponibilidad y tolerancia a particiones”
Ejemplos:
C&A: RBDMs
C&P: MongoDB*
A&P: DynamoDB
¿Por qué replicar los datos?Rendimiento en lectura.Al estar los datos en varios nodos, pueden distribuirse las
lecturas entre ellos.
Especialmente importante en datos distribuidos mundialmente.
Tolerancia a particiones de red.
Tolerancia a pérdida de datos por fallo de nodos.Si, por ejemplo, falla el disco duro de un nodo, los datos
siguen estando en los demás.
Nodos para tareas específicas (reportes, backups…).
Por ejemplo… ¡ToroDB!
Replicación en MongoDBVarios nodos forman un replica set.
Cada nodo conoce las direcciones de los demás.
Cada nodo tiene un estado/rol. Los principales son primario y secundario.
Cuando todo va bienLas escrituras del cliente se aplican siempre en el nodo primario.
El nodo primario almacena los cambios en su oplog.
Los nodos secundarios leen de manera constante del oplog, aplicando los cambios que encuentran.
Cuando todo va bienLas escrituras del cliente se aplican siempre en el nodo primario.
El nodo primario almacena los cambios en su oplog.
Los nodos secundarios leen de manera constante del oplog, aplicando los cambios que encuentran.
Se puede leer de los secundarios, pero es una lectura potencialmente inconsistente debido al retardo de replicación.
Canales de comunicación
Canal de datos
Cada nodo secundario escoge un nodo del cual replicar los datos
Canal de feedback
Cada nodo secundario informa de su progreso al nodo del cual replica
Heartbeat
Cada dos segundos, cada nodo envía un mensaje a los demás para mejorar su conocimiento del replica set.
Cuando las cosas van menos bienCuando alguno de los nodos secundarios no reciben noticias del maestro en 10 segs, comienzan una votación para promocionar a primario.
Los nodos pueden votar favorable o desfavorablemente (por ejemplo, si el candidato va más retrasado o si el votante considera que el primario está sano).
Si el candidato obtiene el voto favorable de la mayoría, es promocionado a maestro.
Todo bien...¿Todo controlado?
Todo bien...¿Todo controlado?
Cuando las cosas van aún peor: RollbacksLos rollbacks ocurren cuando:
1. El nodo primario (amarillo) acepta peticiones sin replicarlas a la mayoría
2. El nodo primario se cae
3. Un nodo secundario promociona a primario (rosa)
4. El nuevo primario acepta escrituras
5. El antiguo primario vuelve a ser visible.
6. El antiguo primario tiene que deshacer sus cambios
Cuando las cosas van aún peor: RollbacksUn rollback implica perder escrituras que se suponían guardadas.
Para evitar rollbacks es necesario asegurarse que cada escritura ha sido replicada a la mayoría de los nodos antes de confirmarla al cliente.
Para ello el cliente debe usar la opción w: majority*.
* Esto es especialmente importante en MongoDB 3.2 (ticket SERVER-18453)
En MongoDB Todas las acciones ejecutadas por clientes tienen un tiempo máximo de ejecución.
Cuando se hace una escritura con w: majority se ha de esperar a que la mayoría de los nodos confirmen que han replicado el cambio.
Si la confirmación llega a la vez que el timeout de la ejecución, el cliente puede ver que la operación ha fallado cuando, en realidad, se ha escrito.*
*Probado en 2.4.3
Cuando las cosas van aún peor: Falsos negativos
Cuando todo se complica: Dirty and stale readsLas lecturas sucias y rancias ocurren cuando se lee de un nodo que se cree primario pero que no lo es.
Dirty read
Leer datos que luego sufrirán un rollback.
Stale read:
Leer datos que no están actualizados, pues han sido modificados en el verdadero primario.
Cuando todo se complica: Dirty and stale readsLeer datos incorrectos puede suponer inconsistencias difíciles de detectar en la capa de aplicación.
Estas inconsistencias ocurren incluso cuando se escribe con w: majority.
Las lecturas sucias (dirty reads) pueden evitarse modificando las lecturas con level: majority*.
Las lecturas rancias (stale reads) no pueden evitarse (AFAIK)
* Solo si todos los nodos son MongoDB 3.2
Conclusiones
MongoDB puede facilitar enormemente el desarrollo de aplicaciones.
Permite alcanzar un gran rendimiento si se relajan las condiciones de persistencia y coherencia.
Es fácil relajar las relajar estas condiciones inconscientemente.
Incluso forzando las condiciones más restrictivas, puede producir incoherencias
Conclusiones
MongoDB puede facilitar enormemente el desarrollo de aplicaciones.
Permite alcanzar un gran rendimiento si se relajan las condiciones de persistencia y coherencia.
Es fácil relajar las relajar estas condiciones inconscientemente.
Incluso forzando las condiciones más restrictivas, puede producir incoherencias
Agradecimientos a...
MongoDB IncPor su software
¡Por su documentación!
➢ De las cuales se han usado varios diagramas.
Especialmente a Spencer T Brody.
➢ Cuya charla en MongoDB World 2016 inspira esta.
Kyle Kingsbury, o AphyrPor disfrutar torturando sistemas distribuidos y describir los
resultados de manera amena
Por sus diagramas, algunos de los cuales se han usado en la presentación