Redis Cluster maneja las fallas del nodo a través de una combinación de detección de fallas, promoción de réplicas y gestión del estado del clúster para garantizar la operación continua y la disponibilidad de datos. Está diseñado para sobrevivir a las fallas de algunos nodos promoviendo automáticamente réplicas para reemplazar maestros inalcanzables, manteniendo la integridad del espacio clave al tiempo que minimiza los riesgos de pérdida de datos.
Comunicación del clúster y detección de fallas
Los nodos de clúster Redis se comunican a través de un protocolo binario basado en TCP dedicado llamado Redis Cluster Bus. Cada nodo mantiene conexiones con cualquier otro nodo en el clúster utilizando este bus, lo que permite verificaciones de salud continuas y propagación de estado. Los nodos envían periódicamente paquetes de ping para confirmar el estado operativo de sus pares y compartir información sobre el estado del clúster. Esta comunicación utiliza un protocolo de chismes para difundir eficientemente la información del clúster, ayudando en la detección de fallas de nodo.
Los nodos monitorean a los pares utilizando un mecanismo de ping activo. Si un nodo no responde a pings dentro de un período de tiempo de espera configurado (node_timeout), se marca como posiblemente falla con un estado de Pfail. Esta es una indicación de falla tentativa, lo que significa que el nodo puede ser inalcanzable o hacia abajo, pero aún no está confirmado. Si la condición PFAIL persiste y es confirmada por la mayoría de los nodos maestros, el nodo se marca como falla, lo que indica que el clúster lo considera inalcanzable o hacia abajo. Este mecanismo de detección de fallas basado en el consenso ayuda a prevenir falsos positivos en la identificación de nodos fallidos.
Manejo de fallas de nodo maestro
Cuando un nodo maestro se marca como Fail, Redis Cluster inicia un proceso de conmutación por error para promover una de sus réplicas para convertirse en el nuevo maestro. Este proceso es activado automáticamente por el detector de falla del clúster sin intervención administrativa. La réplica promovida se hace cargo de la responsabilidad de servir a las espacios hash administrados previamente por el maestro fallido, asegurando que el clúster pueda continuar cumpliendo solicitudes sin reconfiguración manual.
La conmutación por error ocurre solo si hay al menos una réplica disponible y accesible para promover. Si no existe una réplica adecuada, el clúster ingresa a un estado de error en el que dejará de aceptar consultas para evitar servir datos inconsistentes. Esto resalta la importancia de tener réplicas configuradas para cada maestro para mantener una alta disponibilidad.
Mecánica de conmutación por error y seguridad
Durante la conmutación por error, la réplica espera sincronizar completamente con el maestro que está reemplazando, asegurando que haya procesado todas las actualizaciones pendientes para evitar la pérdida de datos. Logra esto coincidiendo con la compensación de replicación con el maestro, por lo que tiene un conjunto de datos actualizado antes de asumir el papel maestro.
Una vez sincronizada, la réplica solicita una nueva época de configuración de la mayoría de los maestros. La época es una marca de tiempo lógica utilizada para rastrear los cambios de configuración en el clúster. Después de obtener consenso, la réplica transmite la configuración actualizada a todos los nodos, anunciando su promoción al maestro y la degradación del antiguo maestro a la réplica o la eliminación.
El antiguo maestro, cuando se recupera, recibe esta actualización de configuración y deja de servir consultas como maestro. Redirige las solicitudes de los clientes al nuevo maestro, asegurando que los clientes continúen interactuando de manera transparente con el clúster sin intervención manual.
Manejo de particiones de red y escenarios de cerebro dividido
Redis Cluster utiliza un consenso basado en la mayoría para evitar problemas de cerebro dividido durante las particiones de red. Un Maestro solo será fracasado si es inalcanzable por más de la mitad de los maestros en el clúster. Los maestros que no pueden comunicarse con la mayoría dejarán de aceptar escrituras, evitando los estados de datos divergentes entre particiones.
Sin embargo, si una partición minoritaria contiene clientes que continúan escribiendo a un maestro antes de la conmutación por error, existe la posibilidad de pérdida de escritura. Redis mitiga este riesgo al rechazar las escrituras en el lado minoritario después de un tiempo de espera y en el lado de la mayoría fallando rápidamente sobre el maestro inalcanzable.
A pesar de estas precauciones, las escrituras se pueden perder durante las ventanas de conmutación por error porque Redis usa una replicación asíncrona entre maestros y réplicas. Dado que las respuestas para escribir comandos y actualizaciones de replicación se envían casi simultáneamente, la ventana para perder escrituras es muy estrecha pero no imposible.
Opciones de configuración que afectan el manejo de fallas
Redis Cluster incluye opciones de configuración que influyen en la disponibilidad y el comportamiento durante las fallas de nodo:
-`clúster-require-full-coverage` (predeterminado sí): el clúster deja de aceptar escrituras si se descubre alguna parte del espacio clave debido a fallas de nodos, asegurando una fuerte consistencia de datos.
-`cluster-allow-lees-when-down` (predeterminado no): controla si las lecturas están permitidas cuando el clúster está en un estado de falla. Habilitar esto permite las lecturas de nodos incluso durante fallas parciales, pero puede arriesgarse a que se atiendan datos obsoletos.
Estas configuraciones permiten a los administradores equilibrar la disponibilidad y la consistencia en función de los requisitos de aplicación.
Soporte de conmutación por error manual
Además de la conmutación por error automática, Redis Cluster proporciona un comando manual de conmutación por error que se puede emitir en nodos de réplica. Esto es útil para escenarios de mantenimiento o prueba en los que un administrador desea intercambiar roles maestros sin esperar un evento de falla real.
La conmutación por error manual funciona bloqueando a los clientes en el maestro actual, esperando que la réplica se ponga al día por completo y luego promueva la réplica con una transición atómica suave. Esto garantiza que no hay pérdida de datos durante el cambio de roles y una interrupción mínima para los clientes.
Resumen
Redis Cluster maneja las fallas del nodo principalmente a través de un sistema de detección de fallas y conmutación por error basado en el monitoreo continuo a través del bus de clúster Redis y un protocolo de chismes. Los nodos detectan maestros inalcanzables y promueven réplicas automáticamente después de un proceso de consenso que requiere que la mayoría de los maestros acuerden la falla. La conmutación por error está diseñada para minimizar la pérdida de datos asegurando que las réplicas estén completamente sincronizadas antes de la promoción. Las particiones de red se administran a través de decisiones basadas en la mayoría para evitar condiciones de cerebro dividido, aunque puede ocurrir una ventana estrecha de pérdida de escritura debido a la replicación asincrónica. Las opciones de configuración permiten el ajuste de la disponibilidad versus la consistencia durante las fallas, y los comandos manuales de conmutación por error brindan a los operadores control para el mantenimiento.
Esta arquitectura permite a Redis Cluster proporcionar una alta disponibilidad y tolerancia a la partición con la recuperación automática de las fallas de nodo maestro, asegurando que el clúster permanezca operativo y consistente en escenarios de falla.