Questa pagina fornisce una panoramica del failover manuale per Memorystore for Redis. Per scoprire come eseguire un failover, consulta Avvio di un failover manuale.
Che cos'è un failover manuale?
Un'istanza Memorystore for Redis di livello standard utilizza un nodo replica per eseguire il backup del nodo principale. Un normale failover si verifica quando il nodo principale diventa non corretto, causando la designazione della replica come nuova istanza principale. Un failover manuale è diverso da un normale failover perché lo avvii autonomamente. Per maggiori informazioni sul funzionamento della replica di Memorystore for Redis, consulta Alta disponibilità.
Perché avviare un failover manuale?
L'avvio di un failover manuale ti consente di testare la risposta della tua applicazione a un failover. Queste informazioni possono garantire una procedura di failover più agevole se in un secondo momento si verifica un failover imprevisto.
Modalità di protezione dei dati facoltativa
Le due modalità di protezione dei dati disponibili sono:
- Modalità
limited-data-loss
(predefinita). - Modalità
force-data-loss
.
Per impostare la modalità di protezione dei dati, utilizza uno dei seguenti comandi:
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss
o
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss
Come funzionano le modalità di protezione dei dati
La modalità limited-data-loss
riduce al minimo la perdita di dati verificando che la differenza di dati tra l'istanza principale e la replica sia inferiore a 30 MB prima di avviare il failover. L'offset nella tabella principale viene incrementato per ogni byte
di dati che deve essere sincronizzato con le relative repliche. Nella modalità limited-data-loss
, il failover viene interrotto se il delta di offset maggiore tra la primaria e ogni replica è pari o superiore a 30 MB. Se puoi tollerare una maggiore perdita di dati e vuoi eseguire il failover in modo aggressivo, prova a impostare la modalità di protezione dei dati su force-data-loss
.
La modalità force-data-loss
utilizza una catena di strategie di failover per eseguire il failover in modo aggressivo. Non controlla il delta dell'offset tra la tabella principale e le repliche prima di avviare il failover. Potresti potenzialmente perdere più di 30 MB di modifiche ai dati.
Metrica Byte in attesa di replica
La metrica byte in attesa di replica indica quanti byte rimanenti deve copiare la replica prima di eseguire il backup completo della principale. Potresti osservare un aumento dei byte in attesa durante la replica dell'istanza principale alla replica durante un failover. Se il failover viene attivato da un errore hardware, potresti notare che la dimensione in byte in attesa di replica è vuota perché il valore dell'offset non è stato ottenuto fino a quando la nuova replica non è stata riparata dall'errore dell'host.
Puoi accedere a questa metrica nella console Google Cloud nella pagina dei dettagli dell'istanza. Per visualizzare la pagina dei dettagli dell'istanza, fai clic sull'ID istanza nella pagina Elenco istanze del progetto.
In alternativa, accedi a Esplora metriche per il tuo progetto e cerca la metrica redis.googlapis.com/replication/offset_diff.
Quando eseguire un failover manuale
I failover manuali che utilizzano solo la modalità di protezione limited-data-loss
predefinita
risultano positivi se la metrica byte in attesa di replica è inferiore a 30 MB. Se
vuoi eseguire un failover manuale con byte in attesa di replica superiori
a 30 MB, utilizza la modalità di protezione force-data-loss
.
Se stai cercando di preservare il maggior numero possibile di dati, interrompi temporaneamente la scrittura dell'applicazione nell'istanza Redis e attendi di eseguire il failover manuale finché la metrica byte in attesa di replica non raggiunge il valore che ritieni accettabile.
Potenziali problemi che bloccano un failover manuale
L'esecuzione di un failover manuale su un'istanza di livello base non funziona perché le istanze di livello base non hanno repliche a cui può essere eseguito il failover dell'istanza principale.
Se l'istanza Redis non è in stato di esecuzione, un'operazione di failover manuale con perdita di dati limitata non riesce perché è bloccata per la minimizzazione della perdita di dati.
Se stai eseguendo uno script Lua che si esegue a tempo indeterminato, devi usare
force-data-loss
per avviare un failover. In questa situazione, un'operazione di failover con perdita di dati limitata non verrà completata correttamente.Se per l'istanza sono in attesa operazioni incomplete, come l'aumento di scalabilità o l'aggiornamento, l'operazione di failover manuale è bloccata. Per eseguire un failover manuale, devi attendere che l'istanza sia nello stato
READY
.
Connessione dell'applicazione client
Quando viene eseguito il failover del nodo principale sulla replica, le connessioni esistenti a Memorystore for Redis vengono interrotte. Tuttavia, al momento della riconnessione, l'applicazione viene reindirizzata automaticamente al nuovo nodo principale utilizzando la stessa stringa di connessione o lo stesso indirizzo IP.
Verifica di un failover manuale
Puoi verificare il buon esito di un'operazione di failover manuale con la console Google Cloud o gcloud
.
Verifica della console Google Cloud
Prima di avviare un failover manuale, vai alla pagina dell'elenco delle istanze di Memorystore for Redis e fai clic sul nome dell'istanza.
Quindi, nella scheda Configurazione, accanto a Località principale, visualizza la zona in cui si trova il tuo nodo principale. Prendi nota della zona. Controlla di nuovo questa pagina al termine del failover manuale per verificare che il nodo principale abbia cambiato zona.
Verifica di Cloud Monitoring
Per visualizzare le metriche per una risorsa monitorata con Esplora metriche, segui questi passaggi:
-
Nella console Google Cloud, vai alla pagina leaderboard Esplora metriche:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.
- Nell'elemento Metrica, espandi il menu Seleziona una metrica,
digita
Node role
nella barra dei filtri e poi utilizza i sottomenu per selezionare un tipo di risorsa e una metrica specifici:- Nel menu Risorse attive, seleziona Cloud Memorystore Redis.
- Nel menu Categorie di metriche attive, seleziona replication.
- Nel menu Metriche attive, seleziona Ruolo del nodo.
- Fai clic su Applica.
Per rimuovere le serie temporali dalla visualizzazione, utilizza l'elemento Filtro.
Per combinare le serie temporali, utilizza i menu dell'elemento Aggregazione. Ad esempio, per visualizzare l'utilizzo della CPU per le VM, in base alla zona, imposta il primo menu su Media e il secondo menu su zona.
Tutte le serie temporali vengono visualizzate quando il primo menu dell'elemento Aggregazione è impostato su Nessuna aggregazione. Le impostazioni predefinite per l'elemento Aggregazione sono determinate dal tipo di metrica che hai selezionato.
- Per la quota e altre metriche che generano un campione al giorno:
- Nel riquadro Visualizza, imposta Tipo di widget su Grafico a barre in pila.
- Imposta il periodo di tempo su almeno una settimana.
Il grafico di Cloud Monitoring rappresenta i nodi principali e di replica con due linee. Quando la linea di un nodo ha un valore pari a zero sul grafico, si tratta del nodo della replica. Quando la linea di un nodo ha un valore pari a 1 sul grafico, si tratta del nodo principale. Il grafico rappresenta un failover mostrando come le linee passino da uno a zero e da zero a uno, rispettivamente.
Verifica gcloud
Prima di avviare un failover manuale, utilizza il seguente comando per verificare la zona in cui si trova il tuo nodo principale:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Il tuo nodo principale si trova nella zona contrassegnata come currentLocationId
. Prendi nota della zona.
Dopo aver completato un failover manuale, puoi verificare che il nodo principale sia passato a una nuova zona eseguendo di nuovo il comando gcloud redis instances describe
e controllando che currentLocationId
abbia modificato le zone.
Inoltre, l'etichetta locationId
indica la zona in cui hai eseguito inizialmente il provisioning del nodo principale. L'etichetta alternativeLocationId
indica la zona in cui il sistema ha eseguito il provisioning del tuo nodo replica in origine. Ogni volta che si verifica un
failover, l'istanza principale e la replica passano da una zona all'altra. Tuttavia,
le zone associate a locationId
e alternativeLocationId
non
subiscono variazioni.