Clustering | L'istanza secondaria smette di funzionare

Sintomo

Il mancato avvio dell'istanza secondaria è stato osservato in vari scenari come quello che segue:

a) Disattivare il nodo secondario per il Cold Backup e poi avviarlo di nuovo
b) Disattivare il Cluster per le operazioni di manutenzione e quindi avviare i nodi del cluster

Cause

1) Problemi di rete alla fine dell'infrastruttura - Il secondario si imbatte in una situazione di "Read from master timed out"

Soluzione: Controlla la tua infrastruttura di rete e assicurati che non ci siano modifiche o interruzioni del firewall per convalidare se i nodi principali e secondari sono in grado di comunicare tra loro.

2) Sequenza errata seguita per l'avvio dell'arresto dei nodi del cluster - Causa l'esecuzione in una situazione di "Out of Sync"

Analisi e possibile ragione per cui i nodi del cluster sono fuori sincronia

Ci si imbatte in questa situazione a causa di una sequenza impropria di spegnimento e riavvio dei nodi del cluster. Se il server su cui risiedeva l'istanza principale è stato disattivato come parte della regolare manutenzione e il secondario ha assunto il ruolo di nuovo principale ed è stato autorizzato a funzionare come istanza indipendente. In seguito, quando il secondario è stato chiuso e l'istanza principale è stata avviata, il secondario ha rifiutato l'unione e i nodi sono andati fuori sincronia. Come secondario, ci si aspetta che abbia revisioni più recenti. 

Soluzione: 

a) Lasciare che il vecchio nodo secondario venga eseguito come nuovo principale.

b) Avviare il vecchio principale e lasciare che si unisca come secondario corrente per il momento.

c) Consentire al vecchio principale [secondario attuale] di collegarsi al vecchio secondario [nuovo principale] e sincronizzarsi con le ultime revisioni. 

d) Una volta completata la sincronizzazione, è possibile cambiare il ruolo dei nodi principale e secondario semplicemente fermandosi e riavviando il nodo principale [vecchio secondario] corrente.

e) Quando il principale attuale [vecchio secondario] viene arrestato, il secondario attuale [vecchio principale] recupera il ruolo di principale.

3) Cancellazione manuale del file marker Clustered.txt su qualsiasi nodo Cluster fermato - Questo fa sì che l'istanza venga avviata come nodo principale mentre doveva partire come nodo secondario e unirsi ad un principale esistente

Analisi e possibile ragione per cui i nodi del cluster sono fuori sincronia

Se ci si imbatte in una situazione improvvisa o un brutto arresto della propria istanza principale in esecuzione, allora l'istanza principale non può ricongiungersi al cluster dopo il riavvio. Questo può accadere nei casi in cui un'operazione di scrittura era in corso nel momento in cui il nodo principale è stato fermato, o in cui un'operazione di scrittura è avvenuta alcuni secondi prima dell'arresto dell'istanza principale. In questi casi, l'istanza secondaria potrebbe non ricevere tutte le modifiche dall'istanza principale. Quando il principale viene riavviato, CRX rileva che è fuori sincronia con le istanze rimanenti del cluster e l'archivio non si avvia.

Forse, si è tentato di avviare il nodo principale del cluster cancellando manualmente il file cluster.txt. In generale, il cluster.txt non dovrebbe essere cancellato in qualsiasi momento per avviare l'istanza. È un file marker per farci sapere che questa istanza deve unirsi come secondaria la prossima volta che viene avviata. Il nodo del cluster che viene arrestato per ultimo non ha un file cluster.txt in esso. Questo aiuta a identificare che questo nodo è stato l'ultimo nodo principale in esecuzione e dovrebbe essere avviato per primo.

Se questo file è presente, il nodo non può essere avviato come nodo principale. Dovresti ricevere un messaggio come quello che segue.

Spiegazione:

Significa che c'era un altro nodo cluster in esecuzione anche dopo che questo nodo è stato arrestato in modo che il nodo abbia le ultime revisioni e contenuti. Così, l'ultimo nodo che viene arrestato nel cluster sarebbe il nodo principale ogni volta che si avviano i nodi del cluster.

Soluzione:

a) Interrompere il Nodo secondario che ha lanciato l'eccezione Out of Sync

b) Arrestare il nodo principale corrente (che è stato avviato cancellando il file cluster.txt)

c) Avviare il Nodo secondario (in questo caso sarebbe l'ultimo principale in esecuzione poiché ha le ultime revisioni). Questo prenderà il sopravvento come nuovo principale

d) Avviare il Nodo principale che poi si unirà al cluster come secondario

e) Una volta completata la sincronizzazione, è possibile interrompere e avviare il nodo principale in esecuzione (vecchio secondario) per recuperare la coerenza del ruolo del principale che si comporta come principale e secondario che si comporta come secondario

Da tenere a mente in caso di clonazione del principale per creare il secondario

A causa di fastidiosi problemi di shutdown/hard, reboot/network, rete/carenze elettriche, ecc. di uno qualsiasi dei nodi del cluster, se in caso di problemi di sincronizzazione in cui i nodi del cluster non sono più sincronizzati tra loro, allora, come procedura di ripristino, è necessario ripristinarli dal vecchio backup o ricreare il nodo del cluster.

In questi casi, è necessario creare un clone di un nodo cluster e unirlo al cluster come nuovo secondario, per cui è necessario identificare quale nodo era l'ultimo nodo principale in esecuzione, dato che quel nodo dovrebbe contenere i contenuti e le revisioni più recenti. Quindi, si dovrebbe eseguire il backup solo su quel nodo e creare un secondario.