La replicación es el proceso por el cual los datos son copiados, almacenados y actualizados a través de diferentes sistemas de almacenamiento de datos.
La mayoría de la teoría detrás de la replicación ha existido desde los años 70. Con el advenimiento de la computación en la nube y las bases de datos distribuidas, esta información se ha vuelto más importante que nunca para los ingenieros de software profesionales.
Aunque es poco probable que termines construyendo los mecanismos subyacentes que soportan la replicación, entender cómo funciona es bastante útil. Si desarrollas aplicaciones web que sirven a grandes números de usuarios, probablemente uses alguna forma de replicación en producción.
Dedicar tiempo a aprender cómo funciona la replicación es útil para desarrolladores backend. Una comprensión clara de las compensaciones y riesgos de la replicación te ayudará a diseñar sistemas más resilientes y también a recuperarte cuando las cosas salen mal.
Hay una suposición importante que haremos para esta serie de artículos: una copia de todos nuestros datos caben en una sola máquina. Distribuir los datos de una sola base de datos en múltiples máquinas se llama sharding, un tema más avanzado en sistemas de BD distribuidas.
¿Por qué queremos replicación?
Empecemos con una definición simple de replicación:
Replicación significa mantener una copia de nuestros datos en muchas máquinas que están conectadas entre sí usando una red.
Podrías pensar al principio que mantener los mismos datos en varias bases de datos es un desperdicio de recursos, pero hay muchos beneficios asociados con este enfoque:
- Resistencia mejorada: Si tienes solo una base de datos y falla, tu sistema dejará de funcionar. Por otro lado, un sistema con muchas bases de datos puede continuar sirviendo a usuarios incluso si bases de datos individuales fallan. La corrupción de datos también deja de ser una amenaza, ya que puedes usar bases de datos saludables para arreglar las que tienen datos corruptos.
- Tiempos de respuesta más rápidos: Mantener bases de datos cerca de tus usuarios finales reduce el tiempo que toma servir los datos. Mantener tus datos alrededor del globo te ayuda a mejorar la experiencia del usuario para personas que viven en diferentes partes del planeta.
- Escalamiento para más usuarios: Puedes servir operaciones de lectura desde todas tus bases de datos, incrementando el número de usuarios que el sistema puede soportar en un momento dado.
Ahora que sabemos por qué la replicación es algo genial, agreguemos el primer término a nuestro glosario.
- Réplica: Cada nodo (máquina) que almacena una copia de la base de datos.
Sigue al líder
Necesitamos encontrar una manera de asegurar que los datos en cada BD sean consistentes. Si permitimos que cada base de datos reciba solicitudes de escritura (o cualquier solicitud que cambie datos), necesitaríamos actualizar cada otra réplica en el sistema. Una forma más simple de asegurar que los datos permanezcan consistentes es usar replicación líder/seguidor.
En esta forma de replicación, todas las escrituras u otras operaciones que cambian datos son enviadas a la réplica designada como el líder. Después de realizar los cambios localmente, el líder notifica a los seguidores sobre los cambios en los datos. Los seguidores, en respuesta, actualizan su propia copia local de los datos para mantenerse al día con el líder. Puedes leer desde cualquier réplica, pero solo el líder aceptará escrituras.
En resumen, la replicación líder/seguidor funciona así:
- Una de las réplicas es designada como el líder.
- Todas las solicitudes de escritura u otras solicitudes que pueden cambiar datos deben ser enviadas al líder, y solo al líder. Nota que por escritura queremos decir todos los tipos de solicitudes que podrían cambiar datos, incluyendo actualizaciones.
- Cuando el líder recibe una escritura, realiza los cambios en los datos locales.
- Después de que el cambio local está hecho, el líder notifica a todos los seguidores sobre los cambios en los datos. Esto usualmente se envía como un log de replicación con todos los cambios en una ventana de tiempo dada.
- Los seguidores reciben el log de replicación y realizan los cambios a sus copias locales de la base de datos principal. Los cambios se aplican en el mismo orden en que fueron procesados por el líder.
Los detalles entre diferentes implementaciones de líder/seguidor cambian, pero este flujo de trabajo es común en la mayoría de casos.
Sincronicidad
Hay dos tipos principales de replicación: síncrona y asíncrona. El tipo que elijas impactará fuertemente las dinámicas entre seguidores y líder y proporcionará beneficios y desafíos específicos a tu sistema.
Replicación síncrona
En replicación síncrona, el líder espera hasta que todos los seguidores notifiquen que sus actualizaciones fueron realizadas correctamente. Los datos actualizados son visibles a los clientes solo después de que cada seguidor dio el visto bueno.
Este enfoque tiene una ventaja obvia: cada seguidor tendrá una copia actualizada de los datos. Esto significa que no serviremos datos obsoletos a nuestros usuarios. También, si el líder falla, tenemos garantía de tener copias de los datos más recientes.
Por otro lado, la desventaja de este enfoque es bastante peligrosa. Si uno de los seguidores funciona mal (falla o se desconecta) el líder debe bloquear todas las escrituras hasta que la réplica afectada esté disponible otra vez. Esto significa que una falla en un solo nodo detiene todo el sistema.
Porque queremos construir sistemas resilientes, la replicación síncrona raramente se usa como el único enfoque para replicación. La replicación asíncrona se usa mucho más a menudo.
Replicación asíncrona
En replicación asíncrona, el líder no espera por el mensaje Ok de los seguidores. En este caso, incluso si todos los seguidores mueren, el líder continuará procesando escrituras y sirviendo datos. Hay dos cosas a considerar cuando usas replicación asíncrona:
- El líder falla y los datos se pierden: Si el líder falla y los cambios no han sido replicados aún, esos cambios se perderán.
- Los seguidores se quedan atrás del líder por varios minutos: Si tus sistemas empiezan a operar cerca de la capacidad máxima, puede haber un retraso significativo entre tus seguidores y el líder. Esto resulta en seguidores sirviendo datos viejos a los usuarios, algo de lo que podrían no estar contentos. La replicación usualmente es muy rápida, pero si hay una carga significativa en el sistema pueden quedarse atrás varios minutos.
A pesar de las desventajas, las réplicas completamente asíncronas son el escenario más común en sistemas de producción. El hecho de que los datos puedan quedarse atrás algunos segundos es superado por los beneficios de tener réplicas que no tumban todo el sistema si fallan.
Para la mayoría de escenarios de producción realistas, la replicación asíncrona funciona lo suficientemente bien. Te proporcionan los beneficios de la replicación con solo una pequeña cantidad de riesgo.
Semi-síncrona
Hay un tercer tipo de replicación llamada semi-síncrona. En este caso, todos los seguidores excepto uno son asíncronos. Si por alguna razón el seguidor síncrono falla, eliges cualquiera de los seguidores restantes y lo haces síncrono.
¿Qué pasa si las réplicas individuales fallan, se quedan muertas?
Las réplicas fallarán tarde o temprano.
Si eso sucede, necesitas entender y decidir cómo se manejará la recuperación del sistema. Hay muchas técnicas de recuperación diferentes usadas en réplicas de producción, y tener una comprensión básica del proceso te ayudará a entender qué está pasando si esto sucede en uno de tus sistemas.
El siguiente artículo tratará la recuperación en sistemas de datos replicados.
Qué hacer después:
- Comparte este artículo con amigos y colegas. Gracias por ayudarme a llegar a personas que podrían encontrar útil esta información.
- Esta serie está basada en Designing Data-Intensive Applications, asegúrate de echar un vistazo a los capítulos 5 y 6 para una explicación más profunda de replicación y sharding.
- Envíame un email con preguntas, comentarios o sugerencias (está en la página Autor).