URL original:

Introducción

Este artículo presenta el proceso de conmutación por error del clúster de Redis (Cluster).

Solución de problemas

Cuando hay un problema con un nodo en el clúster, debe haber una forma sólida de garantizar que el nodo esté defectuoso. Los nodos en el clúster de Redis implementan la comunicación de nodos a través de mensajes ping/pong. Los mensajes no solo pueden propagar la información de la ranura del nodo, sino también otros estados, como el estado maestro-esclavo, la falla del nodo, etc. Por lo tanto, el descubrimiento de fallas también se realiza a través del mecanismo de difusión de mensajes, y los enlaces principales incluyen: offline subjetivo (pfail) y offline objetivo (fail).

Fuera de línea subjetivo: se refiere a un nodo que considera que otro nodo no está disponible, es decir, el estado fuera de línea.Este estado no es el juicio final de falla, sino que solo representa la opinión de un nodo, y puede haber juicios erróneos.
Objetivo fuera de línea: se refiere a marcar el verdadero fuera de línea de un nodo, y varios nodos en el clúster creen que el nodo no está disponible, alcanzando así un resultado de consenso. Si falla el nodo principal que contiene la ranura, se requiere una conmutación por error para ese nodo.

fuera de línea subjetivo

Cada nodo del clúster envía periódicamente mensajes ping a otros nodos y el nodo receptor responde con mensajes pong. Si la comunicación falla todo el tiempo dentro del tiempo de espera del nodo del clúster, el nodo de envío considerará que el nodo de recepción está defectuoso y marcará el nodo de recepción como un estado subjetivo fuera de línea (pfail). El proceso se muestra en la siguiente figura:

Descripción del proceso:
1) El nodo a envía un mensaje ping al nodo b. Si la comunicación es normal, se recibirá un mensaje pong y el nodo a actualizará la hora de la última comunicación con el nodo b.

2) Si hay un problema de comunicación entre el nodo a y el nodo b, la conexión se desconectará y se volverá a conectar la próxima vez. Si la comunicación falla todo el tiempo, la última hora de comunicación registrada por el nodo a con el nodo b no se puede actualizar.

3) Cuando la tarea de temporización en el nodo a detecta que el tiempo de última comunicación con el nodo b es demasiado alto, el tiempo de espera del nodo de clúster es demasiado alto, actualiza el estado local del nodo b como fuera de línea subjetivo (pfail).

Fuera de línea subjetivo simplemente significa que cuando un nodo no puede completar con éxito la comunicación del mensaje de ping con otro nodo dentro del período de tiempo de espera de nota de clúster, el nodo se marca como un estado fuera de línea subjetivo. La estructura de estado del clúster en cada nodo necesita guardar otra información de nodo, que se utiliza para juzgar el estado de otros nodos desde su propia perspectiva.

El clúster de Redis es muy estricto al juzgar si el nodo finalmente está defectuoso. Solo un nodo piensa que está desconectado subjetivamente y no puede juzgar con precisión si está defectuoso. Por ejemplo la siguiente escena:

La comunicación entre los nodos 6379 y 6385 se interrumpe, lo que hace que 6379 juzgue que 6385 está en un estado fuera de línea subjetivo, pero la comunicación entre los nodos 6380 y 6385 es normal. En este caso, no se puede determinar que el nodo 6385 está defectuoso. Por lo tanto, para un mecanismo sólido de descubrimiento de fallas, solo cuando la mayoría de los nodos en el clúster juzgan que el 6385 está defectuoso, se puede considerar que el 6385 realmente ha fallado y luego se realiza la conmutación por error para el nodo 6385. Este proceso de múltiples nodos que cooperan para completar el descubrimiento de fallas se denomina objetivo fuera de línea.

objetivamente fuera de línea

Cuando un nodo juzga que otro nodo está fuera de línea, el estado del nodo correspondiente seguirá el mensaje para difundirse en el clúster. El cuerpo del mensaje del mensaje ping/pong lleva los datos de estado de otros nodos en el clúster 1/10. Cuando el nodo receptor encuentra que el cuerpo del mensaje contiene el estado subjetivo del nodo fuera de línea, encontrará la estructura ClusterNode del nodo defectuoso localmente y guárdelo en el centro de la lista vinculada del informe sin conexión. La estructura es la siguiente:

struct clusterNode { /* 认为是主观下线的clusterNode结构 */
    list *fail_reports; /* 记录了所有其他节点对该节点的下线报告 */
    ...
};

A través de la propagación de mensajes de Gossip, los nodos del clúster recopilan continuamente informes fuera de línea de nodos defectuosos. Cuando más de la mitad de los nodos maestros que tienen ranuras marcan un nodo como fuera de línea subjetivo. Activar el proceso fuera de línea del objetivo. Hay dos problemas aquí:

1) ¿Por qué el nodo maestro responsable de la ranura debe participar en la decisión de descubrimiento de fallas? Porque en el modo de clúster, solo el nodo maestro que procesa la ranura es responsable del mantenimiento de la información clave, como las solicitudes de lectura y escritura y las ranuras del clúster, mientras que el nodo esclavo solo replica los datos y la información de estado del nodo maestro.

2) ¿Por qué más de la mitad de los slots de procesamiento son masternodes? Más de la mitad de ellos deben usarse para lidiar con la segmentación del clúster causada por particiones de la red y otras razones. El pequeño clúster dividido no puede completar el proceso clave desde fuera de línea subjetivo hasta fuera de línea objetivo, lo que impide que el clúster pequeño continúe brindando servicios externos después de completar la conmutación por error

Suponiendo que el nodo a marca al nodo b como fuera de línea subjetivo, el nodo a envía el estado del nodo b a otros nodos a través de un mensaje después de un período de tiempo, cuando el nodo c recibe el mensaje y analiza el cuerpo del mensaje que contiene el estado pfail del nodo b, activará el objetivo. El proceso fuera de línea se muestra en la siguiente figura:

Descripción del flujo:

Cuando el cuerpo del mensaje contiene el estado pfail de otros nodos, se juzgará el estado del nodo emisor. Si el nodo emisor es el nodo maestro, se procesará el estado pfail notificado y el nodo esclavo lo ignorará.
Encuentre la estructura del nodo correspondiente a pfail y actualice la lista vinculada del informe sin conexión interno de clusterNode.
Intente cerrar la sesión objetivamente de acuerdo con la lista actualizada de informes de cierre de sesión.

Aquí hay una descripción detallada de cómo mantener el informe fuera de línea y tratar de cerrar la sesión objetivamente.

1. Mantener la lista de informes fuera de línea

Habrá una estructura de lista enlazada fuera de línea en la estructura ClusterNode de cada nodo, que guarda los informes fuera de línea de otros nodos maestros para el nodo actual. La estructura es la siguiente:

typedef struct clusterNodeFailReport {
    struct clusterNode *node; /* 报告该节点为主观下线的节点 */
    mstime_t time; /* 最近收到下线报告的时间 */
} clusterNodeFailReport;

El informe fuera de línea guarda la estructura del nodo que informó la falla y la hora en que se recibió recientemente el informe fuera de línea. Cuando se recibe el estado de falla, se mantendrá la lista vinculada de informes fuera de línea y en línea del nodo correspondiente. El pseudocódigo es como sigue:

def clusterNodeAddFailureReport(clusterNode failNode, clusterNode senderNode) :
    // 获取故障节点的下线报告链表
    list report_list = failNode.fail_reports;
    
    // 查找发送节点的下线报告是否存在
    for(clusterNodeFailReport report : report_list):
        // 存在发送节点的下线报告上报
        if(senderNode == report.node):
            // 更新下线报告时间
            report.time = now();
            return 0;
            
        // 如果下线报告不存在,插入新的下线报告
        report_list.add(new clusterNodeFailReport(senderNode,now()));
    return 1;

Cada informe de línea descendente tiene una fecha de caducidad. Cada vez que se activa una línea descendente objetiva, detectará si el informe de línea descendente ha caducado y se eliminará el informe de línea descendente caducado. Si el informe fuera de línea no se actualiza dentro del tiempo de cluster-node-time*2, caducará y se eliminará. El pseudocódigo es el siguiente:

def clusterNodeCleanupFailureReports(clusterNode node) :
    list report_list = node.fail_reports;
    long maxtime = server.cluster_node_timeout * 2;
    long now = now();
    for(clusterNodeFailReport report : report_list):
        // 如果最后上报过期时间大于cluster_node_timeout * 2则删除
        if(now - report.time > maxtime):
            report_list.del(report);

El período de validez del informe fuera de línea es server.cluster_node_timeout*2, que es principalmente para falsos positivos. Por ejemplo, el nodo A informó que el nodo B estuvo fuera de línea en la última hora, pero luego volvió a la normalidad. Ahora hay otros nodos que informan sobre el estado subjetivo del nodo B fuera de línea y, de acuerdo con la situación real, no se pueden usar los falsos positivos anteriores.

Consejos de operación y mantenimiento

Si los informes fuera de línea de más de la mitad de los nodos de ranura no se pueden recopilar dentro del tiempo de nodo de clúster * 2, los informes fuera de línea anteriores caducan, es decir, la velocidad de los informes fuera de línea subjetivos no puede alcanzar la velocidad caducada de los informes fuera de línea. , entonces el nodo fallido nunca se marcará como objetivamente fuera de línea, lo que provocará que falle la conmutación por error. Por lo tanto, no se recomienda establecer un tiempo de nodo de clúster demasiado pequeño.

2. Trate de cerrar la sesión objetivamente

Cada vez que un nodo del clúster recibe el estado pfail de otros nodos, intentará disparar un objetivo fuera de línea, el proceso se muestra en la siguiente figura:

Descripción del flujo:

Primero, cuente la cantidad de informes fuera de línea válidos y salga si es menos de la mitad de la cantidad total de nodos maestros que tienen ranuras en el clúster.
Cuando el informe fuera de línea es mayor que la mitad del número de nodos maestros en la ranura, el nodo defectuoso correspondiente se marca como un estado fuera de línea objetivo.
Transmita un mensaje de error al clúster para notificar a todos los nodos que marquen el nodo fallido como objetivamente fuera de línea. El cuerpo del mensaje de error solo contiene el ID del nodo fallido.

Use pseudocódigo para analizar el proceso fuera de línea objetivo, de la siguiente manera:

def markNodeAsFailingIfNeeded(clusterNode failNode) {
    // 获取集群持有槽的节点数量
    int slotNodeSize = getSlotNodeSize();
    // 主观下线节点数必须超过槽节点数量的一半
    int needed_quorum = (slotNodeSize / 2) + 1;
    // 统计failNode节点有效的下线报告数量（不包括当前节点）
    int failures = clusterNodeFailureReportsCount(failNode);
    // 如果当前节点是主节点， 将当前节点计累加到failures
    if (nodeIsMaster(myself)):
        failures++;
    // 下线报告数量不足槽节点的一半退出
    if (failures < needed_quorum):
        return;
    // 将改节点标记为客观下线状态(fail)
    failNode.flags = REDIS_NODE_FAIL;
    // 更新客观下线的时间
    failNode.fail_time = mstime();
    // 如果当前节点为主节点,向集群广播对应节点的fail消息
    if (nodeIsMaster(myself))
        clusterSendFail(failNode);

Transmitir el mensaje de falla es el último paso de la línea descendente objetiva y asume responsabilidades muy importantes:

Notifique a todos los nodos del clúster para que marquen el nodo defectuoso como un estado fuera de línea objetivo y surta efecto de inmediato.
Notifique al nodo esclavo del nodo fallido para activar el proceso de conmutación por error.

Debe entenderse que, aunque existe un mecanismo de transmisión de mensajes de error, es incierto que todos los nodos del clúster sepan que el nodo fallido entra en el estado fuera de línea objetivo. Por ejemplo, cuando se produce una partición de red, es posible que el clúster se divida en dos clústeres independientes, uno grande y otro pequeño. El clúster grande contiene la mitad de los nodos de ranura y puede completar el objetivo fuera de línea y transmitir el mensaje de falla, pero el clúster pequeño no puede recibir el mensaje de falla, como se muestra en la siguiente figura:

Sin embargo, cuando se restaura la red, siempre que el nodo defectuoso se desconecte objetivamente, eventualmente se propagará a todos los nodos del clúster a través de mensajes de Gossip.

Consejos de operación y mantenimiento

La partición de la red hará que el clúster pequeño dividido no reciba el mensaje de error del clúster grande. Por lo tanto, si todos los nodos esclavos del nodo defectuoso están en el clúster pequeño, la conmutación por error posterior no se completará. La topología del bastidor se reduce. la posibilidad de partición de amo y esclavo.

Recuperación

Después de que el nodo defectuoso se vuelve objetivamente fuera de línea, si el nodo fuera de línea es el nodo maestro que tiene la ranura, debe seleccionar uno de sus nodos esclavos para reemplazarlo, a fin de garantizar la alta disponibilidad del clúster. Todos los nodos esclavos del nodo maestro fuera de línea son responsables de la recuperación de fallas.Cuando el nodo esclavo descubre que el nodo maestro replicado por sí mismo ha ingresado al objetivo fuera de línea a través de tareas de temporización internas, se activará el proceso de recuperación de fallas, como se muestra en la siguiente figura :

1. Verificación de elegibilidad

Cada nodo esclavo debe verificar el tiempo de la última desconexión del nodo maestro para determinar si es elegible para reemplazar
el nodo maestro fallido. Si el tiempo de desconexión entre el nodo esclavo y el nodo maestro excede el tiempo del nodo del clúster*
el factor de validez del esclavo del clúster, el nodo esclavo actual no es elegible para la conmutación por error. El parámetro cluster-slavvalidity-factor se usa para el factor de validez del nodo esclavo, el valor predeterminado es 10.

2. Preparación para el tiempo de elecciones

Cuando el nodo esclavo es elegible para la conmutación por error, el tiempo para activar la elección de la conmutación por error se actualiza y el
proceso subsiguiente solo puede ejecutarse una vez que se alcanza el tiempo. Los campos relacionados con el tiempo de elección de falla son los siguientes:

struct clusterState {
    ...
    mstime_t failover_auth_time; /* 记录之前或者下次将要执行故障选举时间 */
    int failover_auth_rank; /* 记录当前从节点排名 */
}

La razón por la que se adopta aquí el mecanismo de disparo retrasado es principalmente para soportar el problema de prioridad mediante el uso de diferentes tiempos de elección retrasados para múltiples nodos esclavos. Un desplazamiento de replicación más grande indica un nodo esclavo de latencia más baja, por lo que debería tener una prioridad más alta para reemplazar un nodo maestro fallido. El pseudocódigo de cálculo de prioridad es el siguiente:

def clusterGetSlaveRank():
    int rank = 0;
    // 获取从节点的主节点
    ClusteRNode master = myself.slaveof;
    // 获取当前从节点复制偏移量
    long myoffset = replicationGetSlaveOffset();
    // 跟其他从节点复制偏移量对比
    for (int j = 0; j < master.slaves.length; j++):
        // rank表示当前从节点在所有从节点的复制偏移量排名， 为0表示偏移量最大.
        if (master.slaves[j] != myself && master.slaves[j].repl_offset > myoffset):
            rank++;
    return rank;
}

Usando la clasificación de prioridad anterior, actualice el tiempo de activación de la elección, el pseudocódigo es el siguiente:

def updateFailoverTime():
    // 默认触发选举时间： 发现客观下线后一秒内执行。
    server.cluster.failover_auth_time = now() + 500 + random() % 500;
    // 获取当前从节点排名
    int rank = clusterGetSlaveRank();
    long added_delay = rank * 1000;
    // 使用added_delay时间累加到failover_auth_time中
    server.cluster.failover_auth_time += added_delay;
    // 更新当前从节点排名
    server.cluster.failover_auth_rank = rank;

Todos los nodos esclavos con el desplazamiento de replicación más grande activarán el proceso de elección de falla por adelantado, como se muestra en la siguiente figura:

3. Iniciar una elección

Cuando la detección de la tarea de temporización del nodo esclavo alcanza el tiempo de elección de falla (failover_auth_time), el proceso de elección se inicia de la siguiente manera:

(1) Época de configuración de actualización

La época de configuración es un número entero que solo aumenta y no disminuye. Cada nodo maestro mantiene una época de configuración (clusterNode.configEpoch) para indicar la versión del nodo maestro actual. Las épocas de configuración de todos los nodos maestros no son iguales, y el esclavo los nodos copiarán la época de configuración del nodo maestro. Todo el clúster mantiene una época de configuración global (clusterState.current Epoch), que se utiliza para registrar la versión máxima de la época de configuración de todos los nodos principales del clúster. Ejecute el comando de información del clúster para ver la información de la época de configuración:

127.0.0.1:6379> cluster info
...
cluster_current_epoch:15 // 整个集群最大配置纪元
cluster_my_epoch:13 // 当前主节点配置纪元

La época de configuración seguirá al mensaje ping/pong para propagarse en el clúster. Cuando tanto el remitente como el receptor son nodos maestros y la época de configuración es igual, significa que hay un conflicto. La parte con el Id. de nodo más grande incrementará el número global. época de configuración y asignarlo al nodo actual para distinguirlo.Conflicto, el pseudocódigo es el siguiente:

def clusterHandleConfigEpochCollision(clusterNode sender) :
    if (sender.configEpoch != myself.configEpoch || !nodeIsMaster(sender) || !nodeIsMast
        (myself)) :
    return;
    
    // 发送节点的nodeId小于自身节点nodeId时忽略
    if (sender.nodeId <= myself.nodeId):
        return
        
    // 更新全局和自身配置纪元
    server.cluster.currentEpoch++;
    myself.configEpoch = server.cluster.currentEpoch;

El papel principal de la era de la configuración:

Indica las diferentes versiones de cada nodo maestro en el clúster y la versión más grande del clúster actual.
Cada vez que ocurre un evento importante en el clúster, el evento importante aquí se refiere a la aparición de un nuevo nodo maestro (recién unido o convertido de un nodo esclavo), y los nodos esclavos compiten por la elección. Todo incrementará la época de configuración global del clúster y la asignará al nodo principal correspondiente para registrar este evento clave.
El nodo principal tiene una época de configuración más grande para representar el estado del clúster actualizado. Por lo tanto, cuando se intercambian mensajes ping/pong entre nodos, si hay inconsistencias en la información clave, como las ranuras, la parte con la época de configuración más grande prevalecerá para evitar la desactualización. mensajes El estado contamina el clúster.

Los escenarios de aplicación para configurar epoch son:

Se agregan nuevos nodos.
Detección de colisión de mapeo de nodos de ranura.
Votación de nodos esclavos para detección de conflictos electorales.

Consejos de desarrollo

Anteriormente, al modificar el mapeo de nodos de ranura a través del comando cluster setslot, era necesario asegurarse de que la época de configuración local (configEpoch) del nodo maestro que ejecutaba la solicitud fuera el valor máximo, de lo contrario, la información de la ranura modificada no se transmitiría al nodo con una época de configuración más alta durante la propagación del mensaje. Dado que el mecanismo de comunicación de Gossip no puede saber con precisión qué nodo es la época de configuración más grande actual, el comando clustersetslot{slot}node{nodeId} al final de la tarea de migración de ranuras debe ejecutarse una vez en todos los nodos maestros.

Cada vez que un nodo esclavo inicia una votación, la época de configuración global del clúster se incrementará automáticamente y se almacenará por separado en la
variable clusterState.failover_auth_epoch para identificar la versión de la elección iniciada por el nodo esclavo esta vez.

(2) Transmitir mensaje electoral

Transmita el mensaje de elección (FAILOVER_AUTH_REQUEST) en el clúster y registre el estado del mensaje que se ha enviado para garantizar que el nodo esclavo solo pueda iniciar una elección dentro de una época de configuración. El contenido del mensaje es el mismo que el mensaje de ping, pero el tipo se cambia a FAILOVER_AUTH_REQUEST.

4. Votación electoral

Solo el nodo maestro que tiene la ranura procesará el mensaje de elección de falla (FAILOVER_AUTH_REQUEST), porque cada nodo que tiene la ranura tiene un voto único en una época de configuración, cuando recibe el primer mensaje de nodo esclavo que solicita un voto Responda al mensaje FAILOVER_AUTH_ACK como un voto , y luego se ignorarán los mensajes de elección de otros nodos esclavos en la misma época de configuración.
El proceso de votación es en realidad un proceso de elección de líder. Por ejemplo, hay N nodos maestros que tienen espacios en el grupo que representan N votos. Dado que el nodo maestro que tiene una ranura en cada época de configuración solo puede votar por un nodo esclavo, solo un nodo esclavo puede obtener N/2+1 votos, lo que garantiza que se pueda encontrar el único nodo esclavo.

El clúster de Redis no utiliza directamente los nodos esclavos para la elección del líder, principalmente porque la cantidad de nodos esclavos debe ser mayor o igual a 3 para garantizar que haya suficientes N/2+1 nodos, lo que provocará el desperdicio de recursos de nodos esclavos. La elección del líder se realiza utilizando todos los nodos maestros que tienen espacios en el clúster, incluso si solo hay un nodo esclavo para completar el proceso de elección.

Cuando el nodo esclavo recopila los votos de N/2+1 nodos maestros que tienen ranuras, el nodo esclavo puede realizar la operación de reemplazar el nodo maestro. Por ejemplo, hay 5 nodos maestros que tienen ranuras en el clúster y hay 4 nodos maestros. nodos después de la falla del nodo maestro B. Cuando uno de los nodos esclavos obtiene 3 votos, el representante tiene suficientes votos para reemplazar el nodo maestro, como se muestra en la siguiente figura:

Consejos de operación y mantenimiento

El nodo maestro defectuoso también se cuenta en el número de votos. Se supone que la escala de nodos en el clúster es de 3 maestros y 3 esclavos, de los cuales 2 nodos maestros se implementan en una máquina. Cuando esta máquina deja de funcionar, el esclavo los nodos no pueden recopilar 3/3 2+1 votos primarios harán que falle la conmutación por error. Esta pregunta también se aplica al enlace de búsqueda de fallas. Por lo tanto, al implementar un clúster, todos los nodos maestros deben implementarse en al menos 3 máquinas físicas para evitar problemas de un solo punto.

Votación nula: cada época de configuración representa un ciclo de elección. Si no se obtiene una cantidad suficiente de votos de los nodos dentro del período de tiempo de espera de nodo de clúster * 2 después de que comience la votación, la elección se anulará. El nodo esclavo incrementa la época de configuración e inicia la siguiente ronda de votación hasta que la elección sea exitosa.

5. Reemplace el nodo maestro

Cuando se recopilan suficientes votos de los nodos esclavos, se activa la operación de reemplazo del nodo maestro:

El nodo esclavo actual cancela la replicación y se convierte en el nodo maestro.
Ejecute la operación clusterDelSlot para revocar las ranuras de las que es responsable el maestro defectuoso y ejecute clusterAddSlot para delegar estas ranuras en sí mismo.
Transmita su propio mensaje pong al clúster, informando a todos los nodos del clúster que el nodo esclavo actual se ha convertido en el nodo maestro y se ha hecho cargo de la información de la ranura del nodo maestro defectuoso.

tiempo de conmutación por error

Después de introducir el proceso de descubrimiento y recuperación de fallas, podemos estimar el tiempo de conmutación por error en este momento:

Tiempo de identificación subjetivo fuera de línea (pfail) = clúster-nodo-tiempo de espera.
Tiempo de propagación subjetivo del mensaje de estado fuera de línea <=cluster-node-timeout/2.
1. El mecanismo de comunicación de mensajes enviará un mensaje de ping a los nodos que no se comunican que excedan el tiempo de espera de nodo de clúster/2, y el cuerpo del mensaje dará prioridad al nodo de estado fuera de línea al seleccionar qué nodos incluir, por lo que generalmente más de la mitad de los nodos maestros se pueden recopilar durante este período de tiempo pfail report para completar el descubrimiento de fallas.
Tiempo de transferencia del esclavo <= 1000 ms.
1. Debido al mecanismo de elección retrasada, el nodo esclavo con el mayor desplazamiento retrasará la elección como máximo 1 segundo. Por lo general, la primera elección tendrá éxito, por lo que el tiempo que tarda el nodo esclavo en realizar la transferencia es inferior a 1 segundo.

Según el análisis anterior, el tiempo de conmutación por error se puede estimar de la siguiente manera:

failover-time(毫秒) ≤ cluster-node-timeout + cluster-node-timeout/2 + 1000

Por lo tanto, el tiempo de conmutación por error está estrechamente relacionado con el parámetro de tiempo de espera del nodo del clúster, que tiene un valor predeterminado de 15 segundos. Durante la configuración, se pueden realizar los ajustes apropiados de acuerdo con la tolerancia del negocio, pero cuanto más pequeños, mejor, el consumo de ancho de banda se explicará con más detalle en la siguiente sección.

Simulación de conmutación por error

Los detalles principales de la conmutación por error se han presentado hasta ahora. A continuación, se incluye un análisis del comportamiento de la conmutación por error mediante la simulación del escenario de falla del nodo maestro a través del clúster creado anteriormente. Utilice kill-9 para cerrar por la fuerza el proceso del nodo maestro 6385, como se muestra en la siguiente figura:

Confirmar el estado del clúster:

Forzar el cierre del proceso 6385:

análisis de registros

1. La replicación entre el nodo esclavo 6386 y el nodo maestro 6385 se interrumpe y el registro es el siguiente:

2. Los nodos maestros 6379 y 6380 marcaron el 6385 como fuera de línea subjetivo, y más de la mitad de ellos se marcaron como estado fuera de línea objetivo, y se imprimieron los siguientes registros:

3. El nodo esclavo identifica el nodo maestro que está replicando y prepara el tiempo de elección después de ingresar el objetivo fuera de línea.El registro imprime el retraso de elección de 964 milisegundos y lo ejecuta, e imprime el desplazamiento de replicación del nodo esclavo actual.

4. Después de que llega el tiempo de elección retrasada, el nodo esclavo actualiza la época de configuración e inicia una elección fallida.

5. Los nodos maestros 6379 y 6380 votan por el nodo esclavo 6386, el registro es el siguiente:

6. Después de obtener 2 votos de nodo maestro del nodo, más de la mitad de ellos realizan la operación de reemplazar el nodo maestro para completar la conmutación por error:

Restaurar manualmente un nodo

Una vez que la conmutación por error se completa con éxito, recuperamos el nodo fallido 6385 y observamos si el estado del nodo es correcto:

1) Reinicie el nodo fallido 6385.

2) Después de que el nodo 6385 se inicie y descubra que su ranura responsable está asignada a otro nodo, prevalecerá la configuración de clúster existente y se convertirá en el nodo esclavo del nuevo nodo maestro 6386. El registro de claves es el siguiente: