Informazioni sul failover manuale

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 di replica per eseguire il backup del nodo principale. Un normale failover si verifica quando il nodo primario diventa non integro e, di conseguenza, la replica viene designata come nuovo primario. Un failover manuale è diverso da un failover normale perché viene avviato autonomamente. Per saperne di più sul funzionamento della replica di Memorystore for Redis, consulta Alta disponibilità.

Perché avviare un failover manuale?

L'avvio di un failover manuale consente di verificare in che modo l'applicazione risponde a un failover. Questa conoscenza può garantire un processo di failover più fluido in caso si verifichi un failover imprevisto in un secondo momento.

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 nei dati tra l'istanza principale e la replica sia inferiore a 30 MB prima di avviare il failover. L'offset sull'unità principale viene incrementato per ogni byte di dati che deve essere sincronizzato con le relative repliche. In modalità limited-data-loss, il failover verrà interrotto se il delta di offset massimo tra l'istanza principale e ogni replica è pari o superiore a 30 MB. Se puoi tollerare una perdita di dati maggiore 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 per eseguire il failover in modo aggressivo. Non controlla il delta di offset tra l'istanza 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 dell'unità principale. Potresti osservare un aumento dei byte in attesa come replica primaria nella replica durante un failover. Se il failover viene attivato da un errore hardware, potresti notare un campo vuoto in byte in attesa di replica, dato che non è stato possibile ottenere il valore di offset fino a quando la nuova replica non è stata corretta 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 sul relativo ID 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 vengono eseguiti 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 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 del livello base non hanno repliche a cui l'istanza principale può eseguire il failover.

  • Se l'istanza Redis non è integro, un'operazione di failover manuale con perdita di dati limitata non va a buon fine perché è bloccata per minimizzare la perdita di dati.

  • Se esegui uno script Lua a tempo indeterminato, devi utilizzare force-data-loss per avviare un failover. In questo caso, un'operazione di failover per la perdita di dati limitata non verrà completata correttamente.

  • Se l'istanza ha operazioni incomplete in attesa, come la scalabilità o l'aggiornamento, l'operazione di failover manuale viene bloccata. Per eseguire un failover manuale, devi attendere che l'istanza si trovi nello stato READY.

Connessione dell'applicazione client

Quando il nodo principale esegue il failover sulla replica, le connessioni esistenti a Memorystore for Redis vengono eliminate. 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 l'esito positivo 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 Posizione principale, visualizza la zona in cui si trova il nodo principale. Annota la zona. Controlla di nuovo questa pagina dopo aver completato il failover manuale per confermare che il nodo principale abbia cambiato zona.

Verifica di Cloud Monitoring

Per visualizzare le metriche per una risorsa monitorata utilizzando Metrics Explorer, procedi come segue:

  1. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

    Vai a Metrics Explorer

  2. Nell'elemento Metrica, espandi il menu Seleziona una metrica, inserisci Node role nella barra dei filtri, quindi utilizza i sottomenu per selezionare un tipo di risorsa e una metrica specifici:
    1. Nel menu Risorse attive, seleziona Cloud Memorystore Redis.
    2. Nel menu Categorie di metriche attive, seleziona replica.
    3. Nel menu Metriche attive, seleziona Ruolo nodo.
    4. Fai clic su Applica.

  3. Per rimuovere le serie temporali dal display, utilizza l'elemento Filter.

  4. 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 loro zona, imposta il primo menu su Media e il secondo su zone.

    Tutte le serie temporali vengono visualizzate quando il primo menu dell'elemento Aggregation è impostato su Unaggregated. Le impostazioni predefinite per l'elemento Aggregazione sono determinate dal tipo di metrica selezionato.

  5. Per la quota e altre metriche che segnalano un campione al giorno:
    1. Nel riquadro Display, imposta il Tipo di widget su Grafico a barre in pila.
    2. Imposta il periodo di tempo su almeno una settimana.

Il grafico di Cloud Monitoring rappresenta i nodi principali e di replica con due righe. Quando la linea di un nodo ha un valore pari a zero nel grafico, è il nodo di replica. Quando nel grafico la linea di un nodo ha il valore uno, diventa il 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, usa il comando seguente per verificare in quale zona si trova il nodo principale:

gcloud redis instances describe [INSTANCE_ID] --region=[REGION]

Il tuo nodo principale si trova nella zona con l'etichetta currentLocationId. Annota la 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 originariamente il provisioning del nodo principale. L'etichetta alternativeLocationId indica la zona in cui il sistema ha eseguito originariamente il provisioning del nodo di replica. Ogni volta che si verifica un failover principale e di replica tra queste due zone. Tuttavia, le zone associate a locationId e alternativeLocationId non cambiano.