Clúster RedisRedis: conmutación por error del clúster

En la tarea del temporizador del clúster clusterCron, se atraviesan los nodos del clúster y se verifica cada nodo para determinar si está fuera de línea. Hay dos estados relacionados con el nodo fuera de línea: CLUSTER_NODE_PFAIL y CLUSTER_NODE_FAIL.

CLUSTER_NODE_PFAIL: Cuando el nodo actual considera un nodo fuera de línea, cambiará el estado del nodo a CLUSTER_NODE_PFAIL. Debido a la posibilidad de falsos positivos, es necesario decidir si realmente se marca el nodo como fuera de línea*** en función de otros nodos del clúster. NODE_PFAIL se puede interpretar como un tiempo de inactividad sospechoso, similar al tiempo de inactividad subjetivo en un clúster Sentinel.

CLUSTER_NODE_FAIL: si más de la mitad de los nodos del clúster están marcados como fuera de línea, CLUSTER_NODE_FAIL indica que el nodo está realmente fuera de línea, similar al tiempo de inactividad objetivo del clúster Sentinel.

Cuando el temporizador del clúster atraviesa los nodos del clúster para verificar, cada nodo atravesado se marca como un nodo y el nodo actual se marca como yo. El método de verificación es el siguiente:

I. Determinar el número de nodos maestros aislados

Si el nodo actual (es decir, yo mismo) es un nodo esclavo, entonces el nodo que se está atravesando node_NODE_FAIL

Si el nodo actual en sí es un nodo esclavo, es Si el nodo atravesado es un nodo maestro y el nodo no está inactivo, se determinará el número de nodos aislados. Si se cumplen las siguientes tres condiciones, se determina que el nodo es un nodo aislado. nodo, y el número de nodos aislados se incrementa en 1:

Segundo, verifique la conexión

Este paso es principalmente para verificar si la conexión entre los nodos es normal.

Este paso es principalmente para verificar si la conexión entre los nodos es normal. Es posible que el nodo esté en un estado normal, pero hay un problema con la conexión. se liberará y la conexión se volverá a conectar la próxima vez que se ejecute la tarea programada. Se deben cumplir las siguientes condiciones para liberar la conexión:

3. Juicio de puntos de apagado sospechosos

ping_delay registra la distancia desde la hora actual hasta el envío de ping_delay y registra el tiempo desde que se envió el último mensaje de ping al nodo Hora, data_delayd registra el tiempo desde la última vez que se envió un mensaje desde el nodo al nodo actual. y el mayor entre ping_delay y data_delay se toma como tiempo de retraso.

Si el tiempo de retraso es mayor que el tiempo de espera, determine si el nodo ya está en CLUSTER_NODE_PFAIL o CLUSTER_NODE_FAIL. De lo contrario, establezca el estado del nodo en CLUSTER_NODE_PFAIL para considerar que el nodo sospechoso está fuera de línea.

Después de completar la verificación anterior, determine si el nodo actual es un nodo esclavo. Si no está en el estado CLUSTER_MODULE_FLAG_NO_FAILOVER, llame a clusterHandleSlaveFailover para manejar la conmutación por error, pero tenga en cuenta que en este momento, el nodo está. Sólo está configurado para sospechar que está fuera de línea. Sin embargo, cabe señalar que solo se sospecha que el nodo está fuera de línea en este momento y no cumple con las condiciones de conmutación por error. Debe esperar a que el nodo entre en el estado FAIL fuera de línea y luego ejecutar el temporizador del clúster nuevamente en la función clusterHandleSlaveFailover antes de poder comenzar a manejar la conmutación por error.

Cuando el nodo actual piensa que un nodo está fuera de línea, establecerá el estado del nodo en CLUSTER_NODE_PFAIL, es decir, sospecha que el nodo está fuera de línea y cuando intercambia información periódicamente con los nodos del clúster, Es decir, el estado fuera de línea del nodo se registra en el cuerpo del mensaje. Cuando envía un mensaje PING, otros nodos registrarán el estado inactivo del nodo al procesar el mensaje PING recibido.

Los nodos que se consideran fuera de línea se agregarán a la lista de nodos fuera de línea fail_reports y se llamará a la función markNodeAsFailingIfNeeded para determinar si es necesario colocar el nodo en el estado FAIL fuera de línea:

markNodeAsFailingIfNeeded

markNodeAsFailingIfNeeded La función se utiliza para determinar si es necesario marcar el nodo como FAIL:

clusterHandleSlaveFailover

De lo anterior podemos ver que cuando el nodo está fuera de línea, se establecerá en CLUSTER_NODE_FAIL, por lo tanto, la próxima vez que se ejecute el temporizador del clúster por primera vez, en el controlador de conmutación por error clusterHandleSlaveFailover, puede verificar si es FAIL según el estado del nodo.

La próxima vez que se ejecute la tarea del temporizador del clúster, en la función clusterHandleSlaveFailover, puede verificar si es necesario realizar una conmutación por error según el estado.

Sin embargo, antes de comprender la función clusterHandleSlaveFailover, primero echemos un vistazo a las definiciones de variables relacionadas con la elección y la conmutación por error en clusterState:

Algunas variables en la función clusterHandleSlaveFailover

data_age: registra la hora en que el nodo esclavo se sincronizó por última vez con el nodo maestro. Si está conectado al maestro, usa la hora actual menos la hora de la interacción más reciente con el maestro; de lo contrario, usa la hora actual menos la hora en que se interrumpió la replicación entre el maestro y el esclavo.

auth_age: la hora actual menos la hora posterior al inicio de la elección, es decir, la hora posterior al inicio de la elección, se utiliza para determinar si la elección expira y si se debe reiniciar.

need_quorum: el quórum, que es la mitad del número de nodos en el clúster más 1.

auth_timeout: tiempo de espera de espera para la votación.

auth_retry_time: el tiempo de espera a que la elección reinicie la votación, también conocido como tiempo de reintento.

I. Verificación de condiciones de conmutación por error

Primero, se realizan algunas comprobaciones de condiciones para determinar si es necesario realizar una conmutación por error. Si se cumple una de las siguientes condiciones, aparecerá una función. Finalice el proceso de conmutación por error:

Verificación del progreso de la replicación maestro-esclavo. En segundo lugar, la verificación del progreso de la replicación maestro-esclavo

cluster_slave_validity_factor establece el coeficiente máximo de retraso de replicación maestro-esclavo para la conmutación por error. Si el coeficiente no es 0, debe verificar si el retraso de replicación maestro-esclavo cumple con los requisitos.

Si el retardo maestro-esclavo data_age es mayor que el período en el que el mater envía mensajes PING al nodo esclavo + tiempo de espera * factor de retardo maestro-esclavo de conmutación por error, y la conmutación por error no se realiza manualmente, significa que el maestro -El retraso del esclavo es demasiado grande y la transferencia fallida no se puede finalizar.

En tercer lugar, si es necesario reiniciar la elección

Si el tiempo desde la última elección es mayor que el tiempo de reintento del tiempo de espera, significa que la votación se puede reiniciar.

iv. Retraso en el inicio de la elección

v. Inicio de la votación

Si se cumplen las condiciones para el fallo de ejecución, el nodo esclavo debe transmitir a otros nodos. en el cluster Un mensaje para iniciar la votación, aunque solo los masternodes tienen derecho a votar. Si failover_auth_sent es 0, significa que no se ha iniciado la votación y la votación se iniciará en este momento:

6. Realizar conmutación por error

Cuando un nodo obtiene los votos de la mayoría de nodos en el clúster, la conmutación por error es posible.

clusterGetSlaveRank se utiliza para atravesar todos los nodos esclavos del nodo maestro de acuerdo con el progreso de replicación maestro-esclavo repl_offset y calcular el rango del nodo actual. Cuanto mayor sea el valor de repl_offset, más datos tendrá el maestro. El nodo se ha copiado, por lo que cuanto mayor sea el rango, mayor será el valor, menor será el valor del nivel correspondiente.

El nodo esclavo utiliza el valor de nivel como tiempo de retraso al iniciar la elección. Cuanto menor sea el valor, más corto será el tiempo de retraso, lo que significa mayor será la prioridad de la elección.

Cuando el nodo esclavo cree que el nodo maestro ha fallado y necesita iniciar una votación para reelegir al nodo maestro, transmitirá el mensaje CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST al clúster, que se procesa en la función clusterProcessPacket. que llama a la función clusterSendFailoverAuthIfNeeded para sondear:

clusterSendFailoverAuthIfNeeded

La función clusterSendFailoverAuthIfNeeded se utiliza para votar y su lógica de procesamiento es la siguiente:

Si se cumplen las condiciones anteriores se pasan, indica que el nodo actual puede votar por el nodo que emitió la solicitud. Esta actualización lastVoteEpoch, registra la época de la última votación (ronda), actualiza el tiempo de votación de nodo->slaveof->voted_time y luego responde. con un mensaje CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK al nodo que inició la solicitud.

La respuesta del nodo maestro al mensaje CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK enviado por el nodo solicitante también se verificará en el controlador de mensajes clusterProcessPacket con el nodo que envió el mensaje:

Si se cumplen las tres condiciones anteriores se cumplieron simultáneamente, entonces el tiempo_votado es el mismo que el tiempo_votado, y el tiempo_votado es el mismo que el tiempo_votado. Cuando las tres condiciones anteriores se cumplen al mismo tiempo, significa que el remitente ha votado por el nodo actual, actualiza el registro del nodo actual con el número de votos recibidos y agrega 1 a failover_auth_count. En este momento, los votos del. Se puede obtener la mayoría de los nodos y luego la configuración clusterDoBeforeSleep se llama indicador CLUSTER_TODO_HANDLE_FAILOVER, que se mostrará en el bucle. El indicador FAILOVER se llama en el evento de tiempo del período para determinar si se debe realizar una conmutación por error.

Cuando un nodo esclavo recibe una encuesta, agrega el indicador CLUSTER_TODO_HANDLE_FAILOVER y luego ve cómo se maneja el estado CLUSTER_TODO_HANDLE_FAILOVER.

En la función beforeSleep (ubicada en el archivo server.c), si el clúster está activado, se llamará a la función clusterBeforeSleep, que contiene el procesamiento del estado CLUSTER_TODO_HANDLE_FAILOVER:

La función beforeSleep está en Redis Llamada en el método aeMain del bucle de eventos, como se describe en el artículo de análisis del código fuente del marco controlado por eventos.

clusterBeforeSleep

En la función clusterBeforeSleep, si el nodo está marcado con el indicador CLUSTER_TODO_HANDLE_FAILOVER, llamará a la función clusterHandleSlaveFailover para su procesamiento:

La función clusterHandleSlaveFailover nosotros Ya lo he mencionado anteriormente. Mira, esta vez centrémonos en el manejo de la conmutación por error del clúster.

Se puede realizar una conmutación por error si el nodo actual recibe un voto mayoritario, es decir, failover_auth_count es mayor o igual que need_quorum (es decir, la mitad del número de nodos en el clúster + 1). A continuación, se llamará a la función clusterFailoverReplaceYourMaster para completar la conmutación por error.

clusterFailoverReplaceYourMaster

Si un nodo esclavo recibe más de la mitad de los votos en el clúster, puede convertirse en el nuevo nodo maestro y ocupar el puesto del nodo maestro caído. La lógica de procesamiento principal de la función clusterFailoverReplaceYourMaster es la siguiente:

Resumen

Conmutación por error

Si el número de votos obtenidos del nodo excede la mitad del número de vota en el clúster, puede convertirse en el nuevo nodo maestro y ocupar el puesto del nodo maestro caído.