Principio de sincronización maestro-esclavo de Redis

1. ¿Qué es la sincronización maestro-esclavo?

La sincronización maestro-esclavo significa una copia de seguridad redundante de los datos. La base de datos maestra (Maestro) sincroniza los datos de su propia base de datos con la base de datos esclava (Esclavo).

Puede haber una biblioteca esclava o varias bibliotecas esclavas, como se muestra en la figura:

2. ¿Por qué es necesaria la sincronización maestro-esclavo?

Aunque Redis tiene tecnología de persistencia RDB y AOF, puede garantizar que los datos en la memoria no se pierdan cuando se reinicie el servidor (pero esto no significa que los datos no se perderán, aún no estarán disponibles al reiniciar).

Pero si el servidor se apaga y nunca vuelve a funcionar (como por ejemplo una falla de hardware), ¡eso significa que los datos se pierden por completo! Tendrá un impacto significativo en el negocio.

Por tanto, la necesidad de la sincronización maestro-esclavo radica en la alta disponibilidad de datos. Garantiza que cuando falla una máquina, haya otros servidores disponibles para la conmutación por error.

La pregunta es: varios servidores comparten de forma redundante los mismos datos: ¿cómo garantiza Redis la coherencia de los datos?

3. ¿Cómo logra Redis la sincronización maestro-esclavo?

Para resumir brevemente, hay dos puntos:

1. Todas las modificaciones solo se realizan en la biblioteca principal: es decir, la biblioteca principal se puede leer y escribir, y la biblioteca esclava solo se puede leer y no escribir;
2. Las operaciones de escritura se sincronizan desde la base de datos maestra a la base de datos esclava: sincronización completa y sincronización incremental.

(1) Sincronización completa

1. Establecer negociación y sincronización de conexión.

1.1 Utilice el cliente redis-cli para conectarse a la biblioteca esclava, ejecutar  replicaof el comando y especificar la IP y el puerto de la biblioteca principal;

1.2 Después de que la biblioteca esclava responda, ejecute el comando psync, que contiene  el runid de la biblioteca principal  y  el desplazamiento de replicación  :

• runid: genera automáticamente una ID única aleatoria al inicio. Al sincronizar por primera vez, se desconoce el runid de la biblioteca principal, por lo que es  ?;
• offset: Indica el progreso de la replicación, durante la primera sincronización su valor es  -1.

1.3 Después de que la biblioteca maestra recibe el comando psync,  FULLRESYNC responde a la biblioteca esclava con el comando, que también contiene  los dos parámetros de la biblioteca maestra runid  y  el desplazamiento de replicación offset.La  biblioteca esclava registrará estos dos parámetros.

Nota: El comando replicaof es equivalente al comando Slaveof. Antes de Redis 5.0, se usaba el comando Slaveof.

2. Sincronización RDB

2.1 La biblioteca principal ejecuta  bgsave el comando, en este momento  fork el subproceso generará un archivo RDB y el nuevo comando se escribirá en el búfer;

2.2 Enviar archivos RDB a la biblioteca esclava;

2.3 Después de borrar los datos de la base de datos, cargue el archivo RDB.

Nota 1: Para garantizar la coherencia de los datos, bgsave después de la ejecución, la biblioteca principal continuará escribiendo nuevos comandos en el búfer hasta que la biblioteca esclava cargue el RDB;

Nota 2: bgsave crea un subproceso, que es responsable independientemente de la generación de RDB. Durante el proceso de generación de RDB, la biblioteca principal de Redis no se bloqueará y la biblioteca principal aún puede procesar comandos normalmente.

3. Sincronización de comandos

3.1 Después de completar la carga de RDB, la biblioteca esclava responderá un mensaje de confirmación a la biblioteca maestra y la biblioteca maestra enviará el comando de escritura del búfer a la biblioteca esclava;

3.2 La biblioteca esclava recibe el comando de escritura de la biblioteca maestra y lo ejecuta para que los datos maestro-esclavo sean consistentes.

Nota: Después de ejecutar el comando, se mantendrá la conexión larga y el comando de operación de escritura siempre se sincronizará para garantizar la coherencia de los datos maestro-esclavo;

Este proceso también se denomina "propagación de comandos basada en conexiones largas".

(2) Sincronización incremental

Durante el proceso de propagación del comando, si  ocurre una falla en la red  y la conexión se desconecta, los nuevos comandos de escritura no se sincronizarán con la biblioteca esclava en este momento.

Incluso si la conexión de red se desconecta y se restablece después de la fluctuación, la conexión TCP se ha desconectado en este momento y los datos definitivamente deben volver a sincronizarse.

• Antes de Redis 2.8, la base de datos esclava solo podía reiniciar la sincronización completa con la base de datos maestra. Para archivos RDB más grandes, el tiempo de recuperación de la red sería mayor;
• A partir de Redis 2.8, la biblioteca esclava admite la sincronización incremental. Solo los comandos de escritura que no ocurrieron cuando se desconectaron se sincronizarán con la biblioteca esclava.

El proceso detallado es el siguiente:

1. Una vez restaurada la red, la biblioteca esclava emite un comando psync a la biblioteca principal, que transporta el runid devuelto previamente por la biblioteca principal y el desplazamiento copiado;
2. Después de que la biblioteca principal recibe el comando, verifica el runid y el desplazamiento y responde al  CONTINUE comando si no hay ningún problema;
3. La biblioteca maestra envía el comando de escritura durante el período de desconexión de la red y la biblioteca esclava recibe el comando y lo ejecuta.

De hecho, la biblioteca principal hace dos cosas durante el proceso de propagación del comando:

1. Enviar comando de escritura a la biblioteca esclava;
2. Los comandos de escritura se escriben en  repl_backlog_buffer el búfer de trabajo pendiente de replicación , que contiene los comandos de escritura propagados más recientemente.

El búfer de trabajo pendiente de copia es un búfer en anillo. Además de repl_backlog_buffer, la biblioteca principal también tiene el punto de replicación master_repl_offset;

De la misma manera, la biblioteca esclava también tiene el punto de copia esclavo_repl_offset;

Si el desplazamiento se especifica mediante el comando psync de la biblioteca, los datos aún se almacenan en el búfer repl_backlog_buffer, es decir:

master_repl_offset - tamaño <slave_repl_offset, es decir, el desplazamiento mínimo de la biblioteca maestra es menor que el desplazamiento de la biblioteca esclava, lo que indica que los datos todavía están en el búfer de anillo.

Por lo tanto, siempre que el búfer de la biblioteca principal sea lo suficientemente grande para acomodar el último comando de escritura (protocolo Redis), se puede utilizar la sincronización incremental después de una interrupción de la red.

El valor predeterminado repl_backlog_buffer = 1 M. Si la cantidad de datos escritos es grande, como 1 M/s, obviamente, los datos del búfer de copia pendiente dejarán de ser válidos después de 1 segundo de falla de la red, por lo que su valor debe aumentarse.

El tamaño específico debe determinarse según la situación real. Se recomienda configurarlo en más de 10 M, lo que probablemente sea una interrupción en 10 segundos, porque también lleva cierto tiempo iniciar el servidor Redis.