Principio maestro-esclavo de Redis + modo centinela

1. Principio de la replicación maestro-esclavo

①: El servidor esclavo establece una conexión de socket larga antes que el servidor maestro maestro
②: El servidor esclavo esclavo envía un comando PSYNC al servidor maestro maestro para solicitar la replicación de datos.
③: Una vez que el servidor maestro recibe el comando PSYNC, utilizará el subproceso para generar el último archivo de instantánea rdb a través del comando bgsave y enviarlo al servidor esclavo esclavo.
Durante el período de persistencia, el maestro continuará recibiendo solicitudes del cliente y almacenará en caché estas solicitudes que pueden modificar el conjunto de datos en el búfer de respuesta de memoria
④: El esclavo borra los datos inútiles y acepta los datos del maestro para cargarlos en la memoria
⑤: maestro Luego envíe el comando que se almacenó en caché en la memoria durante la persistencia anterior al esclavo.
⑥: El esclavo acepta el nuevo comando enviado por el maestro y lo ejecuta.
⑦: En este momento, los datos se han sincronizado. Cuando el maestro tiene una nueva operación de escritura, se enviará continuamente al esclavo a través de la conexión larga del socket para garantizar la coherencia de los datos maestro-esclavo.
Nota: Si el maestro recibe múltiples solicitudes de conexión simultáneas de múltiples esclavos, solo persistirá una vez, no una sola conexión, y luego enviará esta pieza de datos persistentes a múltiples esclavos conectados simultáneamente.

1. ¿Qué pasa si el nodo esclavo cuelga durante la transmisión maestro-esclavo?

Cuando Salve cuelga cuando recibe la mitad de los datos debido a la red y otras razones, después de un período de tiempo, el nodo esclavo salve se reinicia artificialmente, entonces, ¿cómo se maneja la transmisión de datos en este momento?
Respuesta: A partir de la versión redis 2.8, redis usa el comando PSYNC que admite la replicación de datos parcial para sincronizar los datos con el maestro. El esclavo y el maestro solo pueden realizar la replicación de datos parcial (transmisión reanudada) después de que la conexión de red se desconecta y se vuelve a conectar. El diagrama de flujo es el siguiente:

①: Primero, redis abrirá un grupo de búfer de forma predeterminada cuando se esté ejecutando, que se utiliza para almacenar en caché los últimos comandos de redis. Puede configurar
repl-backlog-size 1mb en 6379.conf #### grupo de búfer de comando de redis, el tamaño predeterminado 1Mb
②: Cuando el esclavo se desconecta del maestro y se restablece la conexión, el esclavo enviará un comando PSYNC al maestro y usará el desplazamiento de compensación para ubicar la posición de la transmisión de datos cuando la conexión se desconecta, y comenzará desde esta posición para continuar la transferencia.
③: Si el nodo esclavo está desconectado durante demasiado tiempo y el desplazamiento es demasiado antiguo, y no se puede encontrar la posición correspondiente en el grupo de búfer de comando en el maestro, se realizará una copia de datos completa. ¡No se puede usar el punto de interrupción para reanudar la carga!

2. ¿Qué es una tormenta de replicación maestro-esclavo?

Tormenta de replicación maestro-esclavo: varios nodos esclavos replican el nodo maestro al mismo tiempo, lo que genera una presión excesiva sobre el nodo maestro.
Para resolver el problema de la tormenta de replicación maestro-esclavo, algunos nodos esclavos pueden sincronizar datos con nodos esclavos. La arquitectura está diseñada de la siguiente manera:

3. Ventajas y desventajas de la replicación maestro-esclavo

1. Ventajas

2. Desventajas

Dos, implementación del proyecto Redis

1. Topología del proyecto

2. Medio ambiente

 一台主服务器  master ：192.168.1.10
两台备服务器   slave1 ：192.168.1.11
             slave2 ：192.168.1.12

1. Instale redis

Es necesario instalar tanto el servidor
activo como el servidor en espera. Transfiera el paquete de instalación de redis a través de archivos xshell

1. Descomprimir

[root@master ~]# tar zxvf redis-5.0.4.tar.gz   
[root@master ~]# cd redis-5.0.4/
[root@master redis-5.0.4]# make 配置安装
[root@master redis-5.0.4]# make DREFIX=/usr/local/redis install
更改安装路径可以用make PREFIX=安装路径 install
[root@master redis-5.0.4]# cd

2. Crea un vínculo

[root@master ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/    
[root@master ~]# cd redis-5.0.4/utils/    
[root@master utils]# ls -lh    查看安装脚本
[root@master utils]# ./install_server.sh    运行脚本
[root@master utils]# netstat -anpt | grep redis   查看端口状态

Después de que la instalación rápida sea exitosa, la configuración básica de Redis está completa

2. Configurar el servicio de replicación maestro-esclavo de Redis

En el servidor maestro

[root@master utils]# cd
[root@master ~]# vi /etc/redis/6379.conf 
[root@master ~]# /etc/init.d/redis_6379 stop    #服务关闭
[root@master ~]# /etc/init.d/redis_6379 start    #服务开启
修改添加
bind 0.0.0.0                     修改监听地址为0.0.0.0
daemonize yes                    开启守护进程
logfile /var/log/redis_6379.log  修改日志文件目录
dir /var/lib/redis/6379          修改工作目录
appendonly yes                   开启AOF持久化功能

Editar la configuración en el dispositivo 1, 2

[root@slave1 utils]# vi /etc/redis/6379.conf 
[root@slave1 utils]# /etc/init.d/redis_6379 restart  服务重启
修改添加
bind 0.0.0.0                 修改监听地址为0.0.0.0
appendonly yes               开启AOF持久化功能
replicaof 192.168.1.10 6379     增加一个同步master节点IP和端口

Ver en el servidor maestro para
verificar el efecto maestro-esclavo

[root@master ~]# tail -f /var/log/redis_6379.log 

Igual que el anterior para el servidor en espera 2

Pruebe la función de replicación de datos maestro-esclavo
en el servidor maestro

[root@master ~]# redis-cli   #进入数据库
127.0.0.1:6379> set fa a     #设置fa键得值为a
127.0.0.1:6379> get fa       #查看fa键得值
127.0.0.1:6379> info replication   #信息复制，状态信息

En el servidor en espera 1

[root@slave1 ~]# redis-cli    #进入数据库
127.0.0.1:6379> get fa        #获取fa键得值
127.0.0.1:6379> info replication     #信息复制，状态信息

En el servidor en espera 2

// An highlighted block
var foo = 'bar';

3. Después de que el servidor principal simulado se cuelga

En el servidor maestro, apague el servicio

[root@master ~]# /etc/init.d/redis_6379 stop      关闭服务
[root@master ~]# tail -f /var/log/redis_6379.log  查看日志

Compruebe el fenómeno en el servidor en espera 1

[root@slave1 ~]# tail -f /var/log/redis_6379.log 查看日志
[root@slave1 ~]# redis-cli                       进入数据库
127.0.0.1:6379> get k                            获取k的键值                    
"aa"                                                  
127.0.0.1:6379> info replication               信息复制，状态信息
# Replication
role:slave                                    状态：从服务器
master_host:192.168.1.10        

En el servidor en espera 2,

puede ver que después de apagar el servidor principal, el estado del servidor esclavo no se convertirá al servidor maestro, pero los datos se copiarán y transferirán, y se podrán leer y ver.

Solución: a
través de la función centinela, el estado del maestro y el esclavo puede cambiar automáticamente cuando falla el servidor maestro

Primero restaure al estado anterior en el
maestro y
reanude en línea

[root@master ~]# /etc/init.d/redis_6379 start      服务启动
[root@master ~]# tail -f /var/log/redis_6379.log   查看日志
[root@master ~]# redis-cli                         进入数据库
127.0.0.1:6379> info replication            信息复制，状态查看
# Replication
role:master          主服务 
connected_slaves:2   连接2个服务器
slave0:ip=192.168.1.11,port=6379,state=online,offset=84,lag=1
slave1:ip=192.168.1.12,port=6379,state=online,offset=84,lag=0
master_replid:087088c1aa398b11c1e4759e93eb8abb6bc277e2
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:84
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:84
127.0.0.1:6379> set nb b      添加nb键值为b
OK
127.0.0.1:6379> get nb        获取nb的键值
"b"

En el servidor en espera 1

[root@slave1 ~]# tail -f /var/log/redis_6379.log   #查看日志
[root@slave1 ~]# redis-cli             

Tres, el principio del modo centinela

• Sentinel Sentinel es un servicio especial de Redis, que no proporciona servicios de lectura y escritura. Se utiliza principalmente para monitorear el estado de los nodos de instancia de Redis.
• Bajo la arquitectura centinela, cuando el cliente solicita el servicio redis por primera vez, primero encontrará el nodo maestro redis del centinela, y luego accederá directamente al nodo maestro redis. No accederá al nodo maestro redis a través del agente centinela cada vez. Cuando el nodo maestro cambia, el centinela lo percibirá por primera vez y notificará al cliente sobre el nuevo nodo maestro de redis (el lado del cliente de redis generalmente implementa la función de suscripción y se suscribe al mensaje de cambio de nodo publicado por Sentinel)
• 

1. El papel principal del centinela

1. Fenómeno

Cuando el nodo principal cuelga, la consola del servidor imprimirá un error de tiempo de espera de conexión.Después de un período de tiempo, vuelve a la normalidad y puede continuar escribiendo datos en redis.

2. Razón

• La razón es que el centinela siempre monitoreará el nodo maestro. Cuando el nodo maestro está inactivo, la consola del servidor imprimirá un error de tiempo de espera de conexión. Pero al mismo tiempo, el centinela confirma que el maestro ha caído por la mitad del mecanismo y elegirá a un esclavo como nuevo maestro.
• Durante el período de elección, la consola seguirá imprimiendo errores. Una vez que la elección sea exitosa, se restablecerá la conexión normal. ¡Esta es también la razón del fenómeno anterior! !
• Cuando se restaure el nodo maestro originalmente colgado, se llamará automáticamente el nuevo nodo del clúster maestro, completando la arquitectura centinela de alta disponibilidad.

El centinela debe establecerse en un número impar, al menos tres, ¡lo que implica votar!

2. Proceso de implementación de Sentinel

Edite el archivo de configuración del modo centinela en el servidor maestro

[root@master ~]# vi redis-5.0.4/sentinel.conf 
修改添加
protected-mode no               关闭安全模式
daemonize yes                   指定sentine1为后台启动，开启守护进程
logfile "/var/log/sentinel.log" 指定日志存放路径
dir /var/lib/redis/6379         指定数据库存放路径

sentinel monitor mymaster 192.168.1.10 6379 2     
指定几个哨兵（slave）检测主服务器故障，才会进行故障迁移（主服务器ip地址，端口号，slave数）

sentinel down-after-milliseconds mymaster 3000  
 判定服务器down掉的时间周期，默认30000毫秒（30秒）
 
sentinel failover-timeout mymaster 100000
故障节点的最大超时时间为100000毫秒（100秒）

Copiar archivos a esclavo1 y esclavo2

[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.11:/root/redis-5.0.4
[root@master ~]# scp redis-5.0.4/sentinel.conf root@192.168.1.12:/root/redis-5.0.4

Inicie el modo centinela
, inicie primero el servidor maestro y luego inicie el servidor esclavo

[root@master ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 69742
[root@slave1 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62685
[root@slave2 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 62250

1. Ver el registro en el servidor maestro

[root@master ~]# tail -f /var/log/sentinel.log 

2. Ver el estado del proceso

[root@master ~]# ps aux | grep redis
[root@master ~]# ps aux | grep sentinel

Indica que se ha iniciado el servicio de centinela
3. Inicie sesión de forma remota en la base de datos para ver el estado del centinela

[root@master ~]# redis-cli -h 192.168.1.10 -p 26379 info sentinel
[root@master ~]# redis-cli -h 192.168.1.10 -p 6379 info replication

1. Simular un problema con el servidor primario y fuera de servicio, verifique el cambio de estado del servidor secundario

En el servidor maestro

[root@master ~]# /etc/init.d/redis_6379 stop  停止服务
[root@master ~]# ps aux | grep redis        查看进程状态

Ver registros en el servidor esclavo

[root@slave1 ~]#  tail -f /var/log/sentinel.log 

Se encontró que el estado maestro se transfiere al esclavo 1

Ver inicio de sesión remoto para ver información de centinela en esclavo2

[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel

2. Ver la dirección del servidor principal detectado por el centinela configurado previamente

En el servidor en espera 1

[root@slave1 ~]# vi redis-5.0.4/sentinel.conf 

Los cambios de dirección de configuración encontrados en el servidor principal también cambiarán automáticamente la dirección de detección cuando el estado principal se cambie automáticamente

3. Ver los cambios de estado cuando el servidor maestro original vuelve a estar en línea

En el servidor maestro

[root@master ~]# /etc/init.d/redis_6379 start  服务启动
[root@master ~]# ps aux | grep redis           查看进程端口状态
[root@master ~]# tail -f /var/log/sentinel.log 查看日志文件

Ver el estado del centinela de la base de datos en slave2

[root@slave2 ~]# redis-cli -h 192.168.1.11 -p 26379 info sentinel

Se descubre que después de que el servidor maestro original se conecte, el estado maestro no volverá a cambiar a sí mismo. Esto es diferente del servicio vrrp porque vrrp tiene una configuración de prioridad, pero el servicio aquí no.