¿Cómo funciona realmente la replicación de bases de datos — líder-seguidor vs multi-líder, y qué puede salir mal?
Una sola copia de tus datos es un punto único de falla — la replicación compra resiliencia y escala de lectura, pero obliga a decidir qué pasa cuando las copias no coinciden.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo funciona realmente la replicación de bases de datos — líder-seguidor vs multi-líder, y qué puede salir mal?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Por qué replicar una base de datos
Una sola instancia de base de datos es un punto único de falla y un techo único para el throughput de lectura. La replicación mantiene copias de los mismos datos en múltiples nodos para que el sistema sobreviva a la pérdida de una máquina, pueda servir lecturas desde el lugar geográficamente más cercano al cliente, y pueda seguir atendiendo tráfico mientras un nodo está caído por mantenimiento. La complejidad que compras a cambio es: ahora hay múltiples copias de la verdad, y hay que decidir qué pasa cuando temporalmente no coinciden.
#Replicación líder-seguidor (single-leader)
En la topología más común, un solo nodo — el líder (o primario/master) — acepta todas las escrituras. Agrega cada escritura a un log de replicación (Postgres lo llama WAL, MySQL lo llama binlog), y uno o más seguidores (réplicas/standbys) transmiten y aplican continuamente ese log para reproducir el estado del líder. Las lecturas pueden servirse desde el líder o, para cargas que toleran datos ligeramente desactualizados, desde un seguidor — la forma más común en que los equipos escalan lecturas sin escalar escrituras.
La replicación hacia los seguidores puede ser síncrona (el líder espera a que al menos un seguidor confirme que tiene la escritura antes de responder al cliente — sin pérdida de datos si el líder falla, pero mayor latencia de escritura) o asíncrona (el líder confirma de inmediato y envía el log en segundo plano — baja latencia, pero un crash del líder puede perder las últimas escrituras que nunca llegaron a ningún seguidor). La mayoría de los sistemas de producción corren un híbrido: un seguidor síncrono para durabilidad, y el resto asíncronos para escalar.
#Replicación multi-líder
La replicación multi-líder permite que más de un nodo acepte escrituras, típicamente un líder por centro de datos, y cada líder replica sus escrituras hacia los demás. El atractivo es obvio para sistemas multi-región: una escritura en Europa no tiene que cruzar un océano para llegar a un único líder en Estados Unidos antes de confirmarse. El costo es igual de obvio: dos líderes pueden aceptar escrituras en conflicto sobre la misma fila casi al mismo tiempo, y ahora el sistema tiene que decidir cómo reconciliarlas, porque no hay un único log que ordene todo.
Las estrategias comunes de resolución de conflictos incluyen last-write-wins (simple, pero descarta silenciosamente una de las escrituras según un timestamp — peligroso si ambas escrituras importaban), guardar ambas versiones y resolver en la aplicación (lo que hacen los "siblings" estilo Dynamo), o usar estructuras de datos que se fusionan de forma determinista sin importar el orden (los CRDT — conflict-free replicated data types — son la respuesta moderna para contadores, conjuntos y estructuras similares).
#Qué puede salir mal: el retraso de replicación
Como los seguidores aplican el log de forma asíncrona, siempre van un poco por detrás del líder — esto es el retraso de replicación (replication lag), y crea bugs reales y visibles para el usuario aunque técnicamente nada haya fallado:
- Violaciones de "lee tus propias escrituras" — un usuario publica un comentario (escrito en el líder), la página se recarga y lee desde un seguidor atrasado, y su propio comentario parece haber desaparecido.
- Violaciones de lectura monótona — un usuario refresca dos veces, golpeando dos seguidores distintos con distinto retraso, y ve un hilo de comentarios más nuevo en el primer refresh y uno más viejo en el segundo.
- Violaciones de causalidad — un usuario ve la respuesta a una pregunta antes de que el seguidor haya replicado la pregunta misma.
Los equipos sortean esto con técnicas como enrutar las propias lecturas de un usuario hacia el líder durante una ventana corta después de escribir, o leer de "la réplica que ya alcanzó al menos el timestamp T."
#Qué puede salir mal: el failover
Cuando un líder muere, algo tiene que promover a un seguidor para que sea el nuevo líder — esto es el failover, y es donde la replicación se vuelve genuinamente peligrosa si se hace de forma ingenua.
Los modos de falla que hay que nombrar en una entrevista:
- Split brain (cerebro dividido) — si el líder anterior solo sufrió una partición de red (no está realmente muerto), puede seguir aceptando escrituras de los clientes que todavía lo ven, al mismo tiempo que un nuevo líder fue promovido y también está aceptando escrituras. Ahora hay dos líderes y datos divergiendo, sin ningún log que ordene entre ellos. Los mecanismos de fencing (STONITH — "dispárale al otro nodo en la cabeza", o un número de generación/época que hace que clientes y seguidores rechacen líderes obsoletos) existen específicamente para evitar esto.
- Escrituras perdidas en la promoción — si el seguidor promovido no estaba completamente al día, las escrituras que solo existían en el líder anterior desaparecen en el momento en que un cliente empieza a escribir en el nuevo.
- Elegir el seguidor equivocado — elegir el seguidor con la posición de replicación más avanzada (no solo "el primero que responde") es en sí mismo un pequeño problema de consenso, por lo que los sistemas serios usan un algoritmo probado (Raft, Paxos, o un servicio de coordinación como ZooKeeper/etcd) en lugar de un script improvisado.