Alta disponibilità per Memorystore for Redis

Questa pagina descrive l'alta disponibilità (HA) per le istanze Memorystore for Redis nel livello Standard.

Panoramica

Il livello standard protegge un'istanza Redis dagli errori comuni replicando i dati su una o più repliche e fornendo un failover automatico rapido a una replica.

Per il livello Standard viene eseguito il provisioning di una principale e una o più repliche. Un'istanza di livello standard con readReplicaMode disabilitato ha una singola replica non di lettura. Un'istanza di livello standard con readReplicaMode abilitato ha da una a cinque repliche di lettura. Per determinare se readReplicaMode è attivato, consulta Visualizzare le informazioni sulle repliche di lettura.

Memorystore for Redis offre alta disponibilità replicando un'istanza Redis principale su una o più repliche. Le modifiche apportate ai dati nell'istanza principale vengono copiate nelle repliche utilizzando il protocollo di replica asincrona di Redis. A causa della natura asincrona della replica, le repliche possono rimanere indietro rispetto al primario a seconda della frequenza di scrittura sul principale.

In caso di errore dell'istanza principale, viene eseguito automaticamente il failover su una replica. Per le istanze configurate con più di una replica, viene eseguito automaticamente il passaggio a una replica sana con il minor tempo di latenza di replica.

Se un'istanza è configurata con una sola replica non di lettura, tutte le connessioni dell'applicazione vengono indirizzate all'endpoint principale. Se un'istanza è configurata utilizzando le repliche di lettura, le applicazioni possono anche sfruttare l'endpoint di lettura per distribuire le query di lettura su tutte le repliche.

Quando viene attivato un failover

Si verifica un failover quando l'istanza principale Redis non funziona. Durante un failover, l'endpoint principale e di lettura reindirizza automaticamente alle nuove istanze principali e alle nuove repliche. Tutte le connessioni all'endpoint principale vengono eliminate, così come le connessioni dell'endpoint di lettura alla replica di lettura promossa.

In che modo un failover influisce sulla tua applicazione

Failover automatico: ref: https://chat.google.com/room/AAAAw0sWhko/WDTlIgNNYHA/WDTlIgNNYHA?cls=10

15 secondi (periodo di tolleranza) + 10-15 secondi (ILB per realizzare il failover) + circa 2 secondi per il ritardo di propagazione medio dell'ILB (https://source.corp.google.com/piper///depot/google3/cloud/hosted/redis/vm/agent/shared/lease_helper.go;l=46-55;rcl=407205391) = 30 secondi.

Failover manuale: 10-15 secondi per il fallimento di 2 controlli di salute e per il failover dell'ILB + circa 2 secondi in media per il ritardo di propagazione dell'ILB - https://source.corp.google.com/piper///depot/google3/cloud/hosted/redis/vm/agent/shared/lease_helper.go;l=46-55;rcl=407205391. <!-->

Quando viene eseguito il failover dell'istanza principale sulla replica, le connessioni esistenti all'endpoint principale dell'istanza vengono interrotte. L'istanza non sarà disponibile per una media di 30 secondi durante le riparazioni automatiche e per 15 secondi per gli eventi di manutenzione. Al ricoinvolgimento, l'applicazione viene reindirizzata automaticamente al nuovo principale utilizzando la stessa stringa di connessione o lo stesso indirizzo IP. Non è necessario aggiornare l'applicazione dopo un failover.

Durante il failover, se sono presenti connessioni all'endpoint di lettura, le connessioni alla replica che viene promossa a principale vengono interrotte. Le connessioni alle altre repliche continuano a essere pubblicate durante il failover. Una volta completato il failover e quando la nuova replica è disponibile, le connessioni vengono reindirizzate alla nuova replica.

Riprovare la connessione dell'istanza dopo il failover

Quando si verifica un failover, tutte le connessioni dall'endpoint principale vengono interrotte e, a seconda del numero di repliche, alcune connessioni di lettura vengono terminate.

A causa di questa perdita di connessione, l'applicazione deve riprovare per ricollegare la connessione. La logica per i nuovi tentativi deve utilizzare il backoff esponenziale per assicurarsi di non sovraccaricare l'istanza con troppe richieste di nuovo tentativo. Oltre a includere la logica di ripetizione, devi testare l'impatto di un failover sulla tua applicazione eseguendo un test con un failover manuale.

La maggior parte dei client Redis dispone di funzionalità di ripetizione integrate che dovresti sfruttare nel caso di interruzione della connessione a causa del failover.

Il failover si verifica nei seguenti scenari:

Se implementi la logica di ripetizione nella tua applicazione per gestire le interruzioni della connessione a causa di failover, la tua istanza non dovrebbe subire un impatto significativo sul rendimento. In genere, i problemi si verificano solo se non è presente la logica di ripetizione.

Come visualizzare lo stato dell'alta disponibilità

Puoi visualizzare le metriche di alta disponibilità per la tua istanza Redis utilizzando Cloud Monitoring. Per informazioni sulle metriche fornite da Cloud Monitoring per Memorystore for Redis, consulta Monitoraggio delle istanze Redis e Metriche di monitoraggio.

Per ulteriori informazioni, consulta la documentazione di Cloud Monitoring.

Per visualizzare lo stato della replica nativa fornito da Redis, puoi emettere il comando Redis INFO all'istanza Memorystore for Redis.