Combate de casos de bases de datos NoSQL - solución de alta disponibilidad de Redis - Redis + sentinel

Prefacio

Este entorno se basa en el sistema Centos 7.8 para crear un entorno de aprendizaje de Redis. Para
una construcción específica, consulte Redis-5.0.9 Implementación del entorno

La sincronización maestro-esclavo de Redis resuelve el problema de la redundancia de datos, pero en varios nodos de Redis, cuando el nodo maestro deja de funcionar, la colección de servidores de Redis se paralizará. Este problema debe resolverse mediante la solución de alta disponibilidad de Redis.
A continuación, me centraré en la solución de alta disponibilidad de Redis: Redis Sentinel

---

Solución de alta disponibilidad de Redis

• Replicación maestro-esclavo (modo Replication-Sentinel)
• Clúster de Redis (modo Redis-Cluster)

1. ¿Qué es un centinela?

Que es un centinela

Sentinel, el nombre en inglés de Sentinel, es un sistema distribuido que se utiliza para monitorear cada servidor en la estructura maestro-esclavo. Cuando el nodo maestro falla, el nuevo nodo maestro se selecciona a través del mecanismo de votación y todos los nodos esclavos se conectan al nuevo nodo maestro.

Sentinel Sentinel es una solución de alta disponibilidad proporcionada oficialmente por redis, que se puede usar para monitorear el estado de ejecución de múltiples instancias del servicio Redis.
Redis Sentinel es un servidor Redis que se ejecuta en un modo especial. Redis Sentinel trabaja de manera cooperativa en el entorno de múltiples procesos de Sentinel.

El papel del centinela

• Monitoreo: el centinela verificará constantemente si su maestro y esclavo funcionan correctamente.
• Notificación: cuando hay un problema con un Redis monitoreado, el centinela puede enviar notificaciones al administrador u otras aplicaciones a través de la API.
• Conmutación por error automática: cuando un maestro no funciona normalmente, el centinela iniciará una operación de conmutación por error automática, que actualizará uno de los esclavos del maestro fallido al nuevo maestro y permitirá que los otros esclavos del maestro fallido copien el nuevo maestro en su lugar. ; cuando el cliente intenta conectarse al maestro fallido, el clúster también devolverá la dirección del nuevo maestro al cliente, de modo que el clúster pueda utilizar el maestro en lugar del maestro fallido.

Arquitectura centinela

Múltiples maestros de monitoreo centinela

Además del maestro de monitoreo, los centinelas se monitorean entre sí

En segundo lugar, la configuración del centinela

Configuración de centinela

El centinela, como monitorización de la instancia de redis, garantiza la robustez y alta disponibilidad del centinela a través del algoritmo de elección. Por lo tanto, el centinela debe estar desplegado al menos 3 unidades, lo que se ajusta al principio de medio número. Necesita 5 o 7, más de la mitad, sin incluir la mitad cuando está vivo Solo cuando se elige al líder se puede realizar la función de conmutación maestro-esclavo.
Al menos un servicio de redis debe sobrevivir para garantizar el funcionamiento normal de centinela. El principio de seleccionar un nuevo maestro es el último disponible y los datos más recientes, la prioridad más alta y el activo más largo

Hay varios puntos a tener en cuenta en el proceso de construcción del sistema centinela.

• Los nodos maestro-esclavo en el sistema centinela no son diferentes de los nodos maestro-esclavo ordinarios. El descubrimiento y transferencia de fallas son controlados y completados por el centinela.
• El ganglio centinela es esencialmente un ganglio redis.
• Para cada nodo centinela, solo necesita configurar el nodo maestro de monitoreo para descubrir automáticamente otros nodos centinela y nodos esclavos.
• Durante la fase de inicio y conmutación por error del nodo centinela, el archivo de configuración de cada nodo se reescribirá (reescritura de configuración).
• Un centinela solo puede monitorear un nodo maestro; de hecho, un centinela puede monitorear múltiples nodos maestros, lo que se puede lograr configurando múltiples monitores centinela.

Preparación ambiental

Se ha configurado y habilitado la sincronización maestro-esclavo de todos los nodos

papel	nodo	ip	Versión Redis
Maestro	reids-yum	192.168.5.11	Redis-5.0.9
esclavo1	reids_source_code	192.168.5.12	Redis-5.0.9
esclavo2	servidor redis	192.168.5.13	Redis-5.0.9

reids_source_code proporciona scripts de servicio del sistema

[root@reids_source_code ~]# vim /usr/lib/systemd/system/redis-sentinel.service
[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/usr/local/redis/bin/redis-sentinel /etc/redis/sentinel.conf --supervised systemd
ExecStop=/usr/bin/kill `pidof redis-sentinel`
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Tres nodos proporcionan archivos de configuración de Sentine

[root@reids-yum ~]# vim /etc/sentinel.conf
[root@reids_source_code redis]# vim /etc/redis/sentinel.conf
[root@redis-server ~]# vim /etc/sentinel.conf 
#是否为守护进程
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
bind 192.168.5.13
port 26379
#工作目录
dir "/var/lib/redis"
#声明该哨兵的主库是mymaster，主库的ip和端口分别为127.0.0.1和6379
#最后一个2的含义是，在哨兵发生领导选举时，该哨兵需要获得2票才能成为leader
sentinel myid c0fc53842608bba5e5807226ce96d7c412bd069b
#在mymaster宕机30秒后进行主观下线
sentinel deny-scripts-reconfig yes
#指定在发生failover故障转移时最多可以有1个slave同时对新的master进行同步
sentinel monitor mymaster 192.168.5.11 6379 2
#设置故障转移超时时间为180秒
#这个参数的意义比较复杂，详细可以参考官方的注释说明
sentinel config-epoch mymaster 0
#发现两个从节点
sentinel leader-epoch mymaster 0
sentinel known-replica mymaster 192.168.5.13 6379
#epoch实现类似版本号的功能
sentinel known-replica mymaster 192.168.5.12 6379
# Generated by CONFIG REWRITE
protected-mode no
sentinel current-epoch 0

Empezar centinela

[root@reids-yum ~]# systemctl start redis-sentinel
[root@reids_source_code ~]# systemctl start redis-sentinel
[root@redis-server ~]# systemctl start redis-sentinel

# 查看进程
[root@reids-yum ~]# netstat -lnutp | grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      8236/redis-server 1 
tcp        0      0 192.168.5.11:6379       0.0.0.0:*               LISTEN      8236/redis-server 1 
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      8077/redis-sentinel 
tcp6       0      0 :::26379                :::*                    LISTEN      8077/redis-sentinel 

[root@reids_source_code ~]# netstat -lnutp | grep 6379
tcp        0      0 192.168.5.12:26379      0.0.0.0:*               LISTEN      3800/redis-sentinel 
tcp        0      0 192.168.5.12:6379       0.0.0.0:*               LISTEN      3265/redis-server 1

[root@redis-server ~]# netstat -lnutp | grep 6379
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      12404/redis-server  
tcp        0      0 192.168.5.13:6379       0.0.0.0:*               LISTEN      12404/redis-server  
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      12326/redis-sentine 
tcp6       0      0 :::26379                :::*                    LISTEN      12326/redis-sentine 

¡El centinela está configurado correctamente! ! !

Ver información del nodo de prueba

Principal

esclavo1

esclavo2

detener el servicio de redis de la biblioteca principal

[root@reids-yum ~]# systemctl stop redis
[root@reids-yum ~]# netstat -lnutp | grep 6379
tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      9751/redis-sentinel 
tcp6       0      0 :::26379  

Ver información del nodo
esclavo1

esclavo2

Redis Sentinel ha logrado con éxito =Conmutación por error maestro-esclavo