Principios básicos del modo centinela de Redis

Sentinel, el nombre chino es Sentinel

Sentinel es un componente muy importante en la arquitectura del clúster redis. Sus funciones principales son las siguientes:

(1) Monitoreo de clúster, responsable de monitorear si los procesos maestro y esclavo de Redis funcionan normalmente

(2) Notificación de mensaje Si una instancia de Redis falla, el centinela es responsable de enviar un mensaje como notificación de alarma al administrador.

(3 ) Conmutación por error, si el nodo maestro cuelga, se transferirá automáticamente al nodo esclavo

(4) Centro de configuración, si se produce una conmutación por error, notifique al cliente del nueva dirección maestra

El propio Sentinel también se distribuye, se ejecuta como un clúster de Sentinel y trabaja en conjunto entre sí

(1) Durante la conmutación por error, la mayoría de los Sentinel deben ponerse de acuerdo para determinar que un nodo maestro está inactivo, implica el problema de la elección distribuida

(2) Incluso si algunos nodos centinela cuelgan, el clúster centinela aún puede funcionar normalmente, porque si un sistema de conmutación por error en sí es importante. parte del mecanismo de alta disponibilidad Es un punto único, por lo que no puede lograr alta disponibilidad.

(1) Sentinel requiere al menos 3 instancias para garantizar su solidez.

(2) La arquitectura de implementación maestro-esclavo de Sentinel redis no garantiza pérdida cero de datos. Solo puede garantizar la. alta disponibilidad del clúster de redis

(3) Para la compleja arquitectura de implementación de Sentinel redis maestro-esclavo, intente realizar suficientes pruebas y simulacros tanto en el entorno de prueba como en el entorno de producción

1 El clúster Sentinel debe implementar más de 2 nodos

Si el clúster Sentinel solo implementa 2 instancias Sentinel, quorum=1

Configuración: quorum = 1

Si el maestro está inactivo, siempre que un centinela en s1 y s2 piense que el maestro está inactivo, se puede realizar el cambio. Al mismo tiempo, se elegirá un centinela en s1 y s2 para realizar la conmutación por error.

En este momento se necesita mayoría, es decir, la mayoría de los centinelas están corriendo. La mayoría de 2 centinelas es 2 (mayoría de 2 = 2, mayoría de 3 = 2, mayoría de 5 = 3, 4). (mayoría=2), ambos centinelas se están ejecutando, lo que permite realizar la conmutación por error.

Pero si toda la máquina que ejecuta M1 y S1 falla, entonces solo hay un centinela y no hay una mayoría que permita la conmutación por error. Aunque hay un R1 en la otra máquina, la falla se transferirá. no se realizará.

2 Clúster Sentinel Clásico

Configuración: quórum = 2, mayoría

Si la máquina donde se encuentra M1 deja de funcionar, quedan 2 centinelas restantes fuera de los tres, S2 y S3 pueden acordar que el maestro está inactivo y luego elegir uno para realizar la conmutación por error.

La mayoría de los tres centinelas al mismo tiempo son 2, por lo que los dos centinelas restantes se están ejecutando, lo que permite realizar la conmutación por error.

Hay dos estados de falla, sdown y odown.

el sdown es un tiempo de inactividad subjetivo. Si un centinela siente que un maestro está inactivo, entonces es un tiempo de inactividad subjetivo.

odown es un tiempo de inactividad objetivo. Si un quórum de centinelas siente que un maestro está inactivo, entonces es un tiempo de inactividad objetivo.

La condición para que se logre la reducción es muy simple. Si un centinela hace ping a un maestro durante más del número de milisegundos especificado por is-master-down-after-millisegundos, se considera subjetivamente que el maestro está en estado de sdown. abajo.

Las condiciones para la conversión de sdown a odown son muy simples. Si un centinela recibe el número especificado de quórum dentro del tiempo especificado, otros centinelas también piensan que el maestro está sdown, entonces se considera odown. y el maestro se considera objetivamente tiempo de inactividad.

Los centinelas se descubren entre sí a través del sistema redis pub/sub. Cada centinela enviará un mensaje al canal centinela: hola. En este momento, todos los demás centinelas pueden consumir este mensaje y percibir la existencia. de otros centinelas

Cada dos segundos, cada centinela enviará un mensaje al centinela: hola canal correspondiente a uno de los maestros esclavos que monitorea, y el contenido es suyo El host, ip y runid también tienen la configuración de monitoreo para este maestro.

Cada centinela también escuchará el canal centinela: hola correspondiente a cada maestro-esclavo que monitorea, y luego detectará la existencia de otros centinelas que también están monitoreando a este maestro-esclavo.

Cada centinela también intercambiará la configuración de monitoreo del maestro con otros centinelas y sincronizará las configuraciones de monitoreo entre sí.

Sentinel será responsable de corregir automáticamente algunas configuraciones del esclavo. Por ejemplo, si el esclavo quiere convertirse en un potencial candidato a maestro, el centinela se asegurará de que el esclavo esté copiando los datos del maestro existente; si el esclavo está conectado a un maestro incorrecto, por ejemplo, después de una conmutación por error, el centinela se asegurará de que esté conectado al maestro correcto

Si se considera que un maestro está fuera de servicio y la mayoría de los centinelas lo permiten conmutación activa/en espera, entonces un determinado centinela realizará la operación de conmutación activa/en espera; en este momento, primero debe elegir un esclavo

Se considerará cierta información sobre el esclavo

. (1) El período de tiempo para desconectarse del maestro

(2 ) prioridad del esclavo

(3) desplazamiento de copia

(4) ID de ejecución

Si un esclavo se desconecta del maestro durante más de 10 milisegundos inactivos, más el tiempo que el maestro está inactivo, entonces el esclavo se considera inadecuado para ser elegido como maestro.

(down-after-millisegundos * 10) milisegundos_since_master_is_in_SDOWN_state

A continuación, se ordenarán los esclavos

(1) Ordenar según prioridad de esclavo, prioridad de esclavo El cuanto menor sea el valor, mayor será la prioridad

(2) Si las prioridades del esclavo son las mismas, mire el desplazamiento de la réplica para ver qué esclavo ha copiado más datos. Cuanto mayor sea el desplazamiento, mayor será. prioridad

(3) Si las dos condiciones anteriores son las mismas, elija un esclavo con una identificación de ejecución más pequeña

Cada vez que un centinela quiera cambiar entre maestro y respaldo, primero un El número de centinelas del quórum se considera reducido. Luego se elige un centinela para realizar el cambio. Este centinela debe ser autorizado por el centinela de la mayoría antes de que pueda realizar el cambio oficialmente.

Si la mayoría del quórum es baja. 5 centinelas, la mayoría es 3 y el quórum se establece en 2. Entonces solo 3 centinelas están autorizados a realizar el cambio.

Pero si el quórum >= mayoría, entonces se debe autorizar el número de quórum de centinelas. Por ejemplo, si hay 5 centinelas y el quórum es 5, entonces los 5 centinelas deben estar de acuerdo. Se requiere autorización para realizar el cambio.

El centinela monitoreará un conjunto de maestros esclavos de Redis y tendrá las configuraciones de monitoreo correspondientes. /p>

El centinela que realiza el cambio cambiará del nuevo maestro a (salve-gt; master) donde obtendrá una época de configuración, que es un número de versión. El número de versión para cada cambio debe ser único

Si el primer cambio centinela elegido falla, otros centinelas esperarán el tiempo de espera de conmutación por error y luego continuarán realizando el cambio. En este momento, se obtendrá una nueva época de configuración como el nuevo número de versión. /p>

Una vez que el centinela completa el cambio, se actualizará y generará localmente. La última configuración maestra se sincroniza con otros centinelas a través del mecanismo de mensajes pub/sub mencionado anteriormente.

La versión anterior. El número aquí es muy importante, porque se publican varios mensajes a través de un canal y monitoreo, por lo que después de que un centinela completa un nuevo cambio, la nueva configuración maestra sigue el nuevo número de versión

Otros centinelas actualizan sus configuraciones maestras en función de el número de versión