Agrupación en clústeres | La instancia esclava deja de funcionar

Síntoma

Si no se puede iniciar la instancia esclava, se observan varios escenarios como los siguientes:

a) Reducir del nodo esclavo para una copia de seguridad pasiva y luego volver a arrancarlo
b) Reducir el clúster para operaciones de mantenimiento y luego iniciar los nodos del clúster

Causas

1) Problemas de red al final de la infraestructura: el esclavo se ejecuta en la situación de Lectura del tiempo maestro agotado

Solución: compruebe la infraestructura de su red y asegúrese de que no haya cambios o interrupciones en el cortafuegos para validar si los nodos maestro y esclavo son capaces de comunicarse entre sí.

2) Secuencia incorrecta seguida para comenzar y detener los nodos del clúster: causando una situación de no sincronización

Análisis y posible razón para los nodos del clúster fuera no sincronizados

Se encuentra en esta situación debido a una secuencia de apagado y reinicio de los nodos del clúster incorrecta. Si el servidor en el que residía la instancia maestra se eliminó como parte del mantenimiento regular y el esclavo asumió el control como nuevo maestro y se permitió que se ejecutara como una instancia independiente. Más adelante, cuando se cerró el esclavo y se inició la instancia maestra, el esclavo rechazó la unión y los nodos no sincronizados. Es algo esperado, ya que el esclavo tendría revisiones más recientes. 

Solución: 

a) Deje que el nodo esclavo antiguo se ejecute como el maestro nuevo.

b) Inicie el maestro antiguo y deje que se una como esclavo actual por ahora.

c) Permita que el maestro antiguo [esclavo actual] se conecte al esclavo antiguo [maestro nuevo] y se sincronice con las últimas revisiones. 

d) Una vez finalizada la sincronización, puede cambiar las funciones de los nodos maestro y esclavo simplemente deteniendo y reiniciando el nodo maestro [esclavo antiguo] actual.

e) Cuando se detiene el maestro actual [esclavo antiguo], el esclavo actual [maestro antiguo] recupera la función de maestro.

3) Eliminación manual del archivo marcador Clistered.txt en cualquier nodo de clúster detenido: esto hace que la instancia se inicie como nodo maestro cuando se suponía que debía iniciarse como nodo esclavo y unirse a un nodo maestro existente.

Análisis y posible razón de los nodos de clúster no sincronizados

Si se encuentra en una situación repentina o un apagado desagradable de su instancia maestra en ejecución, la instancia maestra no puede volver a unirse al clúster después de haberla reiniciado. Esto puede ocurrir en los casos en los que una operación de escritura estaba en curso en el momento en que se detuvo el nodo maestro o cuando se produjo una operación de escritura unos segundos antes de que se detuviera la instancia maestra. En estos casos, es posible que la instancia esclava no reciba todas las modificaciones de la instancia maestra. Cuando se reinicia el maestro, CRX detecta que no está sincronizado con las instancias del clúster restantes y no se iniciará el repositorio.

Es posible que haya intentado iniciar el nodo del clúster maestro eliminando manualmente el archivo clustered.txt. En general, para iniciar la instancia, no se debe eliminar Clustered.txt en ningún momento. Es un archivo marcador para hacernos saber que esta instancia se tiene que unir como esclava la próxima vez que se inicie. El nodo del clúster que se detiene en último lugar no tiene el archivo clustered.txt en él. Esto ayuda a identificar a este nodo como el último nodo maestro en ejecución y el primero que debe iniciarse.

Si este archivo está presente, el nodo no puede iniciarse como nodo maestro. Debería recibir un mensaje como el que se muestra a continuación.

Explicación:

Significa que había otro nodo de clúster ejecutándose incluso después de que este nodo se detuviera, de modo que dicho nodo tiene las últimas revisiones y contenido. Por lo tanto, el último nodo que se detiene en el clúster será el nodo maestro cada vez que inicie los nodos de su clúster.

Solución:

a) Detenga el nodo esclavo que lanzó esta excepción de no sincronizado.

b) Detenga el nodo maestro que se está ejecutando actualmente (que se inició eliminando el archivo clustered.txt).

c) Inicie el nodo esclavo (ya que en este caso sería el último maestro en ejecución porque tiene las últimas revisiones). Esto asumirá la función del nuevo maestro.

d) Inicie el nodo maestro que luego se unirá al clúster como esclavo.

e) Una vez finalizada la sincronización, puede detener e iniciar el nodo maestro que se está ejecutando actualmente (esclavo antiguo) para recuperar la coherencia de las funciones del maestro como maestro y del esclavo como esclavo.

Lo que debe tener en cuenta al clonar al maestro para crear el esclavo

Debido a un apagado desagradable, un reinicio difícil, problemas de red, fallos de alimentación, etc. de cualquiera de los nodos del clúster, si en caso de que se encuentre con un problema de desincronización en el que los nodos del clúster ya no estén sincronizados entre sí, entonces, como procedimiento de recuperación, debe hacer una restauración desde una copia de seguridad antigua o bien volver a crear el nodo del clúster.

En tales escenarios, es necesario crear un clon de un nodo de clúster y unirlo a este como esclavo nuevo. Por lo tanto, es necesario identificar qué nodo fue el último que ejecutó el nodo maestro, ya que ese tendría el contenido y las revisiones más recientes. Luego, solo debe realizar la copia de seguridad en ese nodo y crear un esclavo.