En la última década, el paradigma NoSQL ha irrumpido fuertemente en el mercado de las bases de datos al ofrecer esquemas flexibles y fácil escalado horizontal frente a la rigidez y tediosa configuración de las soluciones SQL tradicionales. Productos como MongoDB, CouchDB o Cassandra resultan especialmente atractivos, entre otras cosas, por ofrecer alta disponibilidad out-of-the-box pero... ¿Cómo funcionan internamente los clusters de estas bases de datos? ¿Cuán transparentes son estos procesos para las aplicaciones cliente? En esta charla se describirá en detalle la replicación de MongoDB, es decir, cómo varias instancias de esta base de datos se comunican entre ellas para ofrecer un sistema resilente y de altas prestaciones. Mediante ejemplos prácticos se mostrará que el correcto uso de MongoDB puede simplificar el desarrollo de aplicaciones pero, también, como un conocimiento insuficiente de la plataforma puede llevar a cometer importantes errores de difícil detección. Gonzalo Ortiz es un Ingeniero de Software que ha enfocado su carrera profesional en torno al desarrollo de bases de datos, lo que le ha llevado hasta 8Kdata, una startup española cuyo objetivo es hacer del trabajo con datos un proceso simple, seguro y eficiente. Actualmente es uno de los principales desarrolladores de ToroDB, la solución de 8Kdata para aunar lo mejor de los mundos SQL y NoSQL.

1. ¿Cómo funciona la
replicación en
MongoDB?
Gonzalo Ortiz Jaureguizar
Software Engineer at 8Kdata
@gortizja

2. Acerca de 8Kdata
Investigación y desarrollo en bases de datos
Desarrolladores de ToroDB.
Una base de datos NoSQL sobre SQL.
Compatible a nivel de protocolo con MongoDB
Disponible con licencia AGPLv3 en Github
http://www.8kdata.com/torodb/

3. Conceptos y
definiciones

4. Replicación
Mantener la misma información en múltiples nodos
Single-master vs Multi-master
Nodo
Proceso que participa en la replicación. En MongoDB los nodos son
procesos Mongod corriendo en la misma o distintas máquinas.
Replica Set
Conjunto de nodos que participan en la replicación
Conceptos y definiciones

5. 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):

6. 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

7. ¿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!

8. Replicación en
MongoDB
Varios 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.

9. Cuando todo va
bien
Las 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.

10. Cuando todo va
bien
Las 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.

11. 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

12. Cuando las cosas
van menos bien
Cuando 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.

13. Todo bien...
¿Todo controlado?

14. Todo bien...
¿Todo controlado?

15. Cuando las cosas
van aún peor:
Rollbacks
Los 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

16. Cuando las cosas
van aún peor:
Rollbacks
Un 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)

17. 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

18. Cuando todo se
complica: Dirty
and stale reads
Las 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.

19. Cuando todo se
complica: Dirty
and stale reads
Leer 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

20. 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

21. 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

22. Agradecimientos a...
MongoDB Inc
Por 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 Aphyr