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 failover normale si verifica quando il nodo principale diventa non integro, facendo sì che la replica venga designata come nuovo nodo principale. Un failover manuale è diverso da un failover normale perché lo avvii tu. Per ulteriori informazioni sul funzionamento della replica di Memorystore for Redis, consulta Alta affidabilità.
Perché avviare un failover manuale?
L'avvio di un failover manuale ti consente di testare la risposta dell'applicazione a un failover. Questa conoscenza può garantire un processo di failover più fluido 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(impostazione 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 tra i dati principali e quelli della replica sia inferiore a 30 MB prima di avviare il failover. L'offset sul nodo 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 più grande tra il nodo principale 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 di offset tra il nodo principale e le repliche prima di avviare il failover; potresti perdere più di 30 MB di modifiche ai dati.
Metrica Byte in attesa di replica
La metrica Byte in attesa di replica indica il numero di byte rimanenti che la replica deve copiare prima che venga eseguito il backup completo del nodo principale. Durante un failover, potresti notare un aumento dei byte in attesa mentre il nodo principale esegue la replica sulla replica. Se il failover viene attivato da un errore hardware, potresti notare che i byte in attesa di replica sono vuoti, poiché il valore di offset non è stato possibile ottenerlo finché la nuova replica non è stata riparata dall'errore dell'host.
Puoi accedere a questa metrica nella Google Cloud console nella pagina dei dettagli dell'istanza. Per visualizzare la pagina dei dettagli dell'istanza, fai clic sull'ID istanza nella pagina dell'elenco delle istanze del progetto.
In alternativa, accedi a Metrics Explorer per il tuo progetto e cerca la metrica redis.googlapis.com/replication/offset_diff.
Quando eseguire un failover manuale
I failover manuali che utilizzano la modalità di protezione limited-data-loss predefinita hanno esito positivo solo 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 conservare 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 è bassa quanto 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 Basic non hanno repliche su cui il nodo principale può eseguire il failover.
Se l'istanza Redis non è integra, un'operazione di failover manuale con perdita di dati limitata non va a buon fine perché è bloccata per la riduzione al minimo della perdita di dati.
Se stai eseguendo uno script Lua che viene eseguito a tempo indeterminato, devi utilizzare
force-data-lossper avviare un failover. In questa situazione, un'operazione di failover con perdita di dati limitata non verrà completata correttamente.Se l'istanza ha operazioni incomplete in attesa, come scalare o aggiornare, l'operazione di failover manuale viene bloccata. Devi attendere che l'istanza sia nello stato
READYper eseguire un failover manuale.
Connessione dell'applicazione client
Quando il nodo principale esegue il failover 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.
Verificare un failover manuale
Puoi verificare l'esito positivo di un'operazione di failover manuale con la
Google Cloud console o gcloud.
Google Cloud Verifica della console
Prima di avviare un failover manuale, vai alla pagina dell'elenco delle istanze Memorystore for Redis, e fai clic sul nome dell'istanza.
Poi, nella scheda Configurazione, accanto a Località principale, visualizza la zona in cui si trova il 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 Metrics Explorer, segui questi passaggi:
-
Nella Google Cloud console, vai alla leaderboard Esplora metriche pagina:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.
- Nella barra degli strumenti della console Google Cloud , seleziona il tuo progetto Google Cloud . Per le configurazioni di App Hub, seleziona il progetto host di App Hub o il progetto di gestione della cartella app.
- Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci
Node rolenella 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 replica.
- Nel menu Metriche attive, seleziona Ruolo nodo.
- Fai clic su Applica.
Per aggiungere filtri, che rimuovono le serie temporali dai risultati della query, 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 riportano un campione al giorno, procedi nel seguente modo:
- Nel riquadro Visualizzazione , 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 nel grafico, si tratta del nodo replica. Quando la linea di un nodo ha un valore pari a uno nel grafico, si tratta del nodo principale. Il grafico rappresenta un failover mostrando come le linee passano rispettivamente da uno a zero e da zero a uno.
Verifica gcloud
Prima di avviare un failover manuale, utilizza il seguente comando per verificare la zona in cui si trova il nodo principale:
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Il nodo principale si trova nella zona etichettata 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 cambiato zona.
Inoltre, l'etichetta locationId indica la zona in cui hai eseguito il provisioning originale del nodo principale. L'etichetta alternativeLocationId indica la zona in cui il sistema ha eseguito il provisioning originale del nodo replica. Ogni volta che si verifica un failover, il nodo principale e la replica passano tra queste due zone. Tuttavia, le zone associate a locationId e alternativeLocationId non cambiano.