En el artículo anterior aprendimos los fundamentos de la replicación y el porqué es útil aprender sobre ella.
También aprendimos sobre replicación líder/seguidor. Seleccionamos una réplica para que sea el líder y los clientes solo podrán enviar operaciones que cambian datos a esta réplica. Después de que una operación de este tipo es procesada por el líder, se le notifica a cada seguidor (las otras réplicas en el sistema) sobre los cambios, y ellos realizan actualizaciones a sus propios datos.
Las réplicas fallarán tarde o temprano, y hay poco que puedas hacer para prevenirlo. Saber cómo los sistemas de replicación manejan la adición de nuevos nodos y cómo se recuperan los datos es importante para entender qué está pasando en tu sistema. Exploremos algunas de las ideas más importantes detrás de la recuperación de fallos en sistemas de replicación.
Agregando nuevos seguidores a la fiesta
El primer tema importante sobre recuperación es la adición de nuevas réplicas. Podrías querer agregar nuevos nodos a tu sistema por dos razones principales:
- Los sistemas necesitan soportar un mayor número de lecturas y quieres agregar nuevas réplicas para mantenerte al día con la demanda.
- Otras réplicas en tu sistema fallaron y necesitas iniciar nuevas para mantener el ritmo con la carga.
Copiar los datos directamente al nuevo nodo usualmente no es suficiente, ya que nuevas escrituras y actualizaciones seguirán llegando. Para cuando tu nodo piense que se puso al día, estará desactualizado. La configuración paso a paso para un nuevo nodo usualmente es así:
- El sistema toma una instantánea/snapshot de los datos en el líder en un punto en el tiempo T dado.
- La instantánea se mueve a la nueva réplica y se usa para recuperar datos hasta el punto T.
- Conectar el seguidor al líder y solicitar todos los cambios que sucedieron desde T.
- Una vez que el seguidor termine de procesar todos los cambios del log, se considera actualizado y puede continuar procesando logs como normal.
Recuperando nodos que ya estaban funcionando
Nuestro sistema debería poder continuar funcionando incluso si nodos individuales fallan. Hay múltiples razones por las que nuestros nodos podrían desconectarse, como fallos o problemas de red. Podríamos incluso reiniciarlos a propósito para instalar actualizaciones de seguridad u otro software. La forma en que los nodos se recuperan depende de su tipo, líderes y seguidores se recuperan usando diferentes medios.
Recuperando seguidores
El proceso de recuperación para seguidores es muy directo:
- Cada seguidor mantiene un log local de los cambios realizados en sus copias locales de los datos.
- Una vez que el seguidor está de vuelta en línea, lee el log y ve qué tan atrasado está actualmente del líder.
- El seguidor solicita todos los cambios que le faltan del líder y procesa los cambios.
- Después de que cada cambio ha sido aplicado a los datos locales, se considera actualizado y continúa trabajando recibiendo el flujo usual de cambios del líder.
Recuperando líderes
Debido a la naturaleza especial del líder, la recuperación usualmente es más complicada que en el caso de los seguidores. También deberíamos estar conscientes de las cosas que pueden salir mal con el proceso. La recuperación involucra designar una nueva máquina como el líder en un proceso llamado failover, que funciona así:
- El sistema detecta si el líder ha fallado. Esto usualmente se hace monitoreando la actividad del líder. Si el líder no responde por un período específico (digamos, 10 segundos) el sistema asume que está muerto e inicia el failover.
- Uno de los seguidores es elegido y promovido a líder. Usualmente, es la réplica con la versión más actualizada de los datos, pero eso no siempre es el caso. La elección de un nuevo líder es una forma de consenso (un tema caliente de investigación en sistemas distribuidos).
- Todos los clientes deben ser reconfigurados para enviar los datos al nuevo líder.
- Los seguidores comienzan a consumir datos del nuevo líder.
- El líder viejo debe ser manejado, ya que podría creer que sigue siendo el líder si regresa en línea. Debes asegurar que se mantenga fuera de línea o asegurar que regrese en línea comportándose como un seguidor.
El proceso parece simple, pero muchas cosas pueden salir mal:
- Si se usa replicación asíncrona, todas las escrituras que los seguidores no han procesado aún se pierden.
- En algunas circunstancias especiales dos nodos pueden creer que son líderes. Recibir actualizaciones de dos líderes puede dañar los datos en las réplicas.
- El timeout debería ser elegido cuidadosamente. Si es muy largo, más datos se perderán, pero si es muy corto podrías iniciar un failover completo en vano. Los aumentos en la carga a veces pueden causar que el líder se retrase un poco, pero sigue funcionando y no se necesita failover. En esa situación, iniciar un failover completo pondrá aún más carga en el sistema.
Recuperación en producción
Acabamos de aprender las ideas básicas detrás de la recuperación del sistema. El proceso de recuperación de la mayoría de implementaciones siguen un esquema similar, así que podrás entender qué está pasando cuando escuches las palabras recuperación y failover en tus sistemas de producción. En sistemas reales, estos procesos pueden ser realizados manualmente por un administrador de sistemas o suceder de una forma totalmente automática.
Hemos estado hablando sobre el log de replicación por un tiempo sin prestarle mucha atención. El flujo de cambios del líder a los seguidores juega un papel muy importante en la replicación. En el siguiente artículo, aprenderemos cómo funciona esto.
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).