Las bases de datos de Redis pueden almacenar objetos pequeños, de corta duración y complejos que persisten durante meses. Independientemente de la complejidad y el tamaño de los objetos, la disponibilidad continua de esos datos es imprescindible para proporcionar un servicio de fondo sin problemas al cliente.Por lo general, la instalación independiente de Redis es fácil de configurar y utilizar. Pero no es la mejor opción para usar en un entorno donde puedan ocurrir fallas de nodo. La durabilidad de los datos se puede conservar con la función Redis solo archivo de archivo (AOF) en Redis, pero no es la solución ideal para la alta disponibilidad. Del mismo modo, los archivos Redis RDB se pueden usar como una opción de copia de seguridad, que es una representación en el tiempo de los datos. Ambas opciones no abordan el problema de las fallas repentinas del nodo Redis.Entonces, Redis introdujo varias características incorporadas para respaldar la alta disponibilidad de bases de datos Redis discutidas en la siguiente sección.

Replicación de la base de datos

La replicación de la base de datos es la técnica fundamental detrás de hacer una tolerancia a fallas del sistema de base de datos y disponible continuamente. La replicación copia los datos de la base de datos maestra (base de datos primaria) a una o más bases de datos de esclavos (réplicas) que aseguran que los datos sean accesibles en cualquier momento si un nodo maestro falla. Este proceso se combina con un proceso automático de conmutación por error que promueve un nuevo maestro de los nodos de réplica disponibles cuando el nodo maestro falla.

Replicación de redis incorporada

Redis comenzó a apoyar la replicación desde sus primeras versiones e inmensamente mejorado. La versión independiente admite la replicación básica con el comando SlaveOF convirtiendo un nodo existente en un esclavo del nodo de base de datos primario. Además, la función Redis Sentinel permite la replicación con una función de conmutación por error más avanzada. Además, el clúster Redis admite un rico conjunto de características de alta disponibilidad para sistemas de bases de datos más distribuidos y grandes.

Replicación básica de Redis con comando SlaveOF

Una de las formas fundamentales de lograr la replicación de Redis es utilizando el comando SlaveOf.

Está a un paso de hacer una instancia de redis un nodo esclavo. La siguiente línea debe agregarse al archivo de configuración de la instancia particular:

esclavo

Caso de uso

El siguiente ejemplo demuestra un escenario en el que una instancia de Redis dada está configurada para ser un nodo esclavo de un nodo maestro que se ejecuta en el 127.0.0.1 dirección en el puerto 7000.

Con esta configuración, la base de datos maestra copiará todos los datos al nodo esclavo que asegura que el esclavo sea una copia exacta del nodo de la base de datos primaria.

Una vez que el nodo maestro está en funcionamiento a las 127.0.0.1 y puerto 7000, iniciemos la otra instancia cuyo archivo de configuración contiene la configuración de SlaveOf. La nueva instancia se ejecutará en el puerto 7001.

La nueva instancia se inicia con éxito y se sincroniza con Master Runs en 127.0.0.1 (puerto 7000).

Si escribe algunos datos en el nodo maestro, se pueden leer del esclavo de la siguiente manera. Significa que el maestro y la réplica se han sincronizado correctamente.

Escribir datos en el nodo maestro se ejecuta en el puerto 7000 de la siguiente manera.

La lectura de datos del nodo esclavo se ejecuta en el puerto 7001 como se muestra en lo siguiente:

Con esta configuración, cuando falla el Redis Master, ya tenemos una copia exacta de la base de datos primaria que se ejecuta en el puerto 7001. Del mismo modo, puede configurar múltiples esclavos para un nodo maestro dado. El único inconveniente en esta configuración es que debe cuidar manualmente el proceso de conmutación por error.

Pros

• Fácil y menos lento para configurar.
• Esta configuración funcionará siempre que esté disponible un solo nodo maestro e incluso sin un solo nodo esclavo.
• Posible automatizar con las herramientas de administración de configuración.

Contras

• El proceso maestro de conmutación por error no está automatizado.
• Dado que las lecturas son asíncronas, pueden ocurrir lecturas rancias.
• La utilización del maestro y los esclavos no es igual debido al fragmento no es compatible.

Alta disponibilidad con Redis Sentinel

Redis Sentinel se introdujo para lidiar con los inconvenientes de la solución anterior. Redis Sentinel es un sistema distribuido que actúa como una solución avanzada de alta disponibilidad para Redis junto con otras características como proveedor de notificaciones, herramientas de monitoreo y proveedor de configuración para clientes.

El centinela es capaz de promover un esclavo a un nodo maestro automáticamente sin ninguna intervención humana. El proceso maestro de conmutación por error comienza si el número máximo especificado de nodos centinela (quórum) está de acuerdo en que el nodo maestro no es accesible. Entonces, la disponibilidad de los nodos centinela es importante. Sin embargo, se recomienda utilizar un clúster centinela separado para ejecutar nodos centinela por separado de los nodos maestros. Con esta configuración, los clientes de Redis hablan primero con el nodo Sentinel y solicitan información sobre el nodo maestro que se ejecuta actualmente. Entonces solo los clientes trabajarán con el maestro actual.

Es posible iniciar un servidor Redis en modo Sentinel como se muestra en el siguiente comando:

servidor de redis --centinela

Como se muestra en la siguiente salida, el servidor se ha iniciado en modo Sentinel.

Además, Redis Sentinels también se puede colocar con los servidores Redis.

Pros

• Característica automática de conmutación por error
• Simple y menos lento para configurar

Contras

• Sentinel necesita un clúster separado si no se coloca con los nodos del servidor Redis
• La utilización del nodo maestro y esclavo está desequilibrado debido a que no hay opción de fragmento disponible
• Redis Sentinel es un sistema distribuido e implica una cantidad considerable de mantenimiento

Alta disponibilidad con agrupación de Redis

Con las últimas versiones de Redis, se agregó un componente de clúster a la pila Redis. Es compatible:

• Fragmento
• Replicación
• Alta disponibilidad

Entonces, el clúster Redis aborda varios aspectos que faltan en soluciones anteriores. Se volvió enormemente beneficioso para las grandes empresas que generan y almacenan una gran cantidad de datos. Porque el fragmento distribuye sus datos entre múltiples maestros, cada uno con un subconjunto de todo el espacio clave. Te da un impulso de rendimiento masivo.

Al mismo tiempo, la replicación está disponible en los grupos de Redis donde puede configurar múltiples nodos esclavos para un maestro dado. Por lo general, un nodo de clúster debe contener exactamente una instancia de servidor Redis. Pero es posible configurar la replicación cruzada implementando múltiples instancias en un solo nodo.

Además, la opción de conmutación por error automática es proporcionada por los grupos Redis donde el nodo esclavo promoverá a un maestro. En una configuración de clúster, el quórum no está obligado a promover un nuevo nodo maestro o fragmento para trabajar. El quórum del nodo maestro solo es necesario para que todo el clúster se ejecute.

Por lo tanto, la solución de clúster Redis puede verse como una solución todo en uno para aquellos que buscan fragmentos, replicación y alta disponibilidad en sus aplicaciones.

Pros

• Admite fragmentos que proporciona un impulso de rendimiento al consultar el almacén de datos Redis.
• Proporciona una solución automática de conmutación por error
• Soporte maestro-replica

Contras

• Mantener un clúster podría ser una cantidad considerable de trabajo
• Falta de soporte de biblioteca

Conclusión

Redis admite una alta disponibilidad con Redis independiente, modelo Redis Sentinel y componente de clúster incorporado. Las tres soluciones tienen sus pros y contras como se discutió anteriormente. En general, Redis Sentinel es la opción de referencia si solo está buscando alta disponibilidad y no le importa el rendimiento. Pero si está buscando un equilibrio entre el rendimiento y la alta disponibilidad con la replicación cruzada, sin duda, el clúster Redis es el mejor entre los tres.