Informazioni sulle repliche di lettura

Il livello Standard di Memorystore for Redis offre la possibilità di scalare le query di lettura dell'applicazione utilizzando le repliche di lettura. Questa pagina presuppone che tu abbia familiarità con le diverse funzionalità dei livelli di Redis di Memorystore.

Le repliche di lettura consentono di scalare il workload di lettura eseguendo query sulle repliche. Viene fornito un endpoint di lettura per semplificare la distribuzione delle query tra le repliche da parte delle applicazioni. Per saperne di più, consulta Scalabilità delle letture con l'endpoint di lettura.

Per istruzioni sulla gestione di un'istanza Redis con repliche di lettura, consulta Gestisci le repliche di lettura.

Casi d'uso per le repliche di lettura

L'archivio di sessioni, la classifica, il motore per suggerimenti e altri casi d'uso richiedono che l'istanza sia ad alta affidabilità. Per questi casi d'uso, le letture sono molto più numerose delle scritture e, in genere, è possibile tollerare alcune letture di dati obsoleti. In casi come questi, è opportuno sfruttare le repliche di lettura per aumentare la disponibilità e la scalabilità dell'istanza.

Comportamento della replica di lettura

  • Le repliche di lettura non sono abilitate per impostazione predefinita nelle istanze di livello Standard.
  • Per proteggere i tuoi dati e fornire un livello di persistenza di base, gli snapshot RDB sono abilitati per impostazione predefinita quando crei un'istanza Memorystore for Redis utilizzando la console Google Cloud .
  • Una volta abilitate su un'istanza, le repliche di lettura non possono più essere disabilitate per quell'istanza.
  • Le istanze di livello Standard possono avere da 1 a 5 repliche di lettura.
  • L'endpoint di lettura fornisce un singolo endpoint per la distribuzione delle query tra i nodi di replica.
  • Le repliche di lettura vengono gestite utilizzando la replica asincrona di Redis.

Avvertenze e limitazioni

  • Le repliche di lettura sono supportate solo per le dimensioni delle istanze con nodi >= 5 GB.
  • Le repliche di lettura possono essere abilitate solo su istanze che utilizzano Redis versione 5.0 o successive.
  • Se specifichi una zona e una zona alternativa per il provisioning dei nodi, Memorystore utilizza queste zone per il primo e il secondo nodo dell'istanza. Successivamente, Memorystore seleziona le zone per tutti i nodi rimanenti di cui è stato eseguito il provisioning per l'istanza.
  • Devi eseguire il provisioning dell'istanza con un intervallo di indirizzi IP CIDR pari o superiore a /28. Le dimensioni degli intervalli più grandi, come /27 e /26, sono valide. Gli intervalli più piccoli, come /29, non sono supportati per questa funzionalità.

Architettura

Quando abiliti le repliche di lettura, specifica il numero di repliche che vuoi nell'istanza. Memorystore distribuisce automaticamente i nodi della replica principale e di lettura tra le zone disponibili in una regione.

Diagramma dell'architettura che mostra Memorystore for Redis livello Standard con repliche di lettura

Ogni istanza ha un endpoint principale e un endpoint di lettura. L'endpoint principale indirizza sempre il traffico al nodo principale, mentre l'endpoint di lettura bilancia automaticamente il carico delle query di lettura tra le repliche disponibili. Nel diagramma, il traffico di lettura e scrittura verso l'endpoint principale è mostrato in blu, mentre il traffico di lettura verso l'endpoint di lettura e le repliche è mostrato in verde.

Il servizio di monitoraggio dell'integrità di Memorystore for Redis monitora l'istanza ed è responsabile del rilevamento di eventuali errori del nodo principale, della scelta di una replica come nuovo nodo principale e dell'avvio di un failover automatico al nuovo nodo principale.

Failover per le istanze con repliche di lettura

Quando un'istanza principale non riesce, il servizio di monitoraggio dell'integrità di Memorystore avvia il failover e la nuova istanza principale viene resa disponibile sia per le letture che per le scritture. Il failover viene generalmente completato in meno di 30 secondi.

Quando si verifica un failover, l'endpoint principale reindirizza automaticamente il traffico al nuovo endpoint principale, ma tutte le connessioni client all'endpoint principale vengono disconnesse durante un failover. Le applicazioni con logica di nuovo tentativo di connessione si riconnetteranno automaticamente quando il nuovo cluster principale sarà online. Alcune connessioni client all'endpoint di lettura vengono inoltre disconnesse dalla replica di lettura che viene promossa a principale durante il failover. Le connessioni alle repliche rimanenti continuano a essere gestite durante un failover. Al nuovo tentativo, le connessioni vengono reindirizzate alle nuove repliche.

Quando si verifica un failover, a causa della natura asincrona della replica, le repliche possono avere un ritardo di replica diverso. Tuttavia, il processo di failover fa del suo meglio per eseguire il failover sulla replica con il ritardo minore. In questo modo, la perdita di dati e la riduzione del throughput di lettura durante un failover sono ridotte al minimo. L'istanza principale appena promossa può trovarsi nella stessa zona o in una zona diversa rispetto all'istanza principale precedente. Viene selezionata una replica come nuova replica principale se si trova nella stessa zona della replica principale precedente e ha il ritardo minore. In caso contrario, una replica di un'altra zona può diventare la nuova replica principale.

Poiché la replica è asincrona, esiste sempre la possibilità di leggere dati inattivi durante un failover. Inoltre, durante la promozione della nuova istanza principale, alcune scritture nell'istanza potrebbero andare perse. Le applicazioni devono essere in grado di gestire questo comportamento.

Redis fa il possibile per evitare che le altre repliche richiedano una sincronizzazione completa durante il failover, ma ciò può accadere in scenari rari. Una sincronizzazione completa può richiedere da qualche minuto a un'ora, a seconda della frequenza di scrittura e delle dimensioni del set di dati da replicare. Durante questo periodo, le repliche sottoposte a una sincronizzazione completa non sono disponibili per le letture. Una volta completata la sincronizzazione, è possibile accedere alle repliche per le letture.

Modalità di errore per le repliche di lettura

Le istanze con repliche di lettura possono riscontrare vari errori e condizioni di stato non integro che influiscono sull'applicazione. Il comportamento varia a seconda che l'istanza abbia una replica o due o più repliche. La sezione descrive alcune modalità di errore comuni e il comportamento dell'istanza in queste condizioni.

Replica non disponibile

  • Quando una replica non riesce per qualsiasi motivo, viene contrassegnata come non disponibile e tutte le connessioni alla replica vengono terminate dopo un determinato timeout. Una volta recuperata la replica, le nuove connessioni vengono indirizzate alla replica ripristinata. Il tempo necessario per recuperare una replica varia in base alla modalità di errore.

  • Se si verifica un errore nella zona, Memorystore for Redis non recupera la replica finché la zona non diventa disponibile.

Errore della zona

  • Se la zona in cui si trova l'istanza principale non funziona, viene eseguito automaticamente il failover dell'istanza principale su una replica in un'altra zona. Se l'istanza ha una sola replica, l'endpoint di lettura non è disponibile per la durata dell'interruzione della zona. Se l'istanza ha più di una replica, le repliche esterne alla zona interessata sono disponibili per le letture

  • Se la zona in cui si trovano una o più repliche non funziona, queste repliche non sono disponibili per la durata dell'errore della zona. Se si verifica un errore in due zone e sono presenti due o più repliche, la replica con il ritardo minore nelle zone rimanenti viene promossa a principale. Eventuali repliche rimanenti nelle zone non interessate sono disponibili per le letture.

Partizione di rete

Una partizione di rete è uno scenario in cui i nodi continuano a funzionare, ma non possono raggiungere tutti i client, le zone o i nodi peer. Memorystore utilizza un sistema basato su quorum per impedire ai nodi isolati di gestire le scritture. In caso di partizione di rete, qualsiasi nodo primario in una partizione di minoranza si retrocede automaticamente. La partizione di maggioranza (se esiste) elegge un nuovo nodo principale se non ne ha già uno. Le repliche isolate continuano a gestire le letture. Tuttavia, potrebbero diventare inattive se non riescono a sincronizzarsi con l'istanza principale.

Per determinare se il link è interrotto, monitora le metriche master_link_down_since_seconds e offset_diff per identificare i nodi isolati.

Sincronizzazione completa

Quando una replica rimane troppo indietro rispetto alla principale, viene attivata una sincronizzazione completa che copia un intero snapshot dalla principale a una replica. Questa operazione può richiedere da pochi minuti a un'ora nel peggiore dei casi. Una sincronizzazione completa non causa un errore dell'istanza, ma durante questo periodo la replica sottoposta alla sincronizzazione completa non è disponibile per le letture e l'istanza principale utilizza più CPU e utilizzo della memoria.

L'endpoint principale restituisce READONLY

Le scritture sull'endpoint principale di un'istanza Memorystore for Redis con repliche di lettura potrebbero ricevere inaspettatamente errori -READONLY You can't write against a read only replica.. Ti consigliamo di chiudere e ricreare le connessioni all'istanza. Nella maggior parte dei casi, il riavvio dell'applicazione client può mitigare il problema. Se queste opzioni non sono fattibili o il comportamento persiste, contatta il team di assistenza Google Cloud .

Scalabilità delle letture con l'endpoint di lettura

Le repliche di lettura consentono alle applicazioni di scalare le letture leggendo dalle repliche. Le applicazioni possono connettersi alle repliche di lettura tramite l'endpoint di lettura.

Endpoint di lettura

L'endpoint di lettura è un indirizzo IP a cui si connette la tua applicazione. Bilancia il carico delle connessioni in modo uniforme tra le repliche nell'istanza. Le connessioni alla replica di lettura possono inviare query di lettura, ma non query di scrittura. Ogni istanza di livello Standard con repliche di lettura abilitate ha un endpoint di lettura. Per istruzioni su come visualizzare l'endpoint di lettura dell'istanza, consulta Visualizza le informazioni sulla replica di lettura per l'istanza.

Comportamento dell'endpoint di lettura

  • L'endpoint di lettura distribuisce automaticamente le connessioni tra tutte le repliche disponibili. Le connessioni non vengono indirizzate all'istanza principale.
  • Una replica è considerata disponibile se è in grado di gestire il traffico dei client. Non sono inclusi i periodi in cui una replica è in fase di sincronizzazione completa con la relativa istanza principale.
  • Una replica con un ritardo di replica elevato continua a gestire il traffico. Le applicazioni con un volume di scrittura elevato possono leggere dati inattivi da una replica che gestisce un volume di scrittura elevato.
  • Se un nodo di replica diventa il nodo principale, le connessioni a quel nodo vengono terminate e le nuove connessioni vengono reindirizzate a un nuovo nodo di replica.
  • Le singole connessioni all'endpoint di lettura hanno come target la stessa replica per la durata della connessione. Non è garantito che connessioni diverse dallo stesso host client abbiano come target lo stesso nodo di replica.

Coerenza di lettura

Le repliche di lettura vengono gestite utilizzando la replica asincrona nativa di Redis OSS. A causa della natura della replica asincrona, è possibile che la replica sia in ritardo rispetto alla replica principale. Le applicazioni con scritture costanti che leggono anche dalla replica devono essere in grado di tollerare letture incoerenti.

Se l'applicazione richiede la coerenza "read your write", ti consigliamo di utilizzare l'endpoint principale sia per le scritture che per le letture. L'utilizzo dell'endpoint principale garantisce che le letture siano sempre indirizzate al nodo principale. Anche in questo caso, è possibile che si verifichino letture di dati obsoleti dopo un failover.

L'impostazione dei TTL sulle chiavi della replica principale garantisce che le chiavi scadute non vengano lette né dalla replica principale né dalla replica. Questo perché Redis garantisce che una chiave scaduta non possa essere letta dalla replica.

Comportamento dell'abilitazione delle repliche di lettura su un'istanza esistente

  • L'abilitazione delle repliche di lettura è un'operazione esclusiva, il che significa che non puoi eseguire altre modifiche dell'istanza con l'operazione di aggiornamento nell'ambito della stessa operazione che abilita le repliche di lettura.

  • Per abilitare le repliche di lettura su un'istanza Redis esistente, devi allocare un intervallo di indirizzi IP secondari valido per il posizionamento dei nodi. Deve essere un intervallo CIDR (Classless Inter-Domain Routing) di dimensioni /28, indipendentemente dalle dimensioni dell'intervallo di indirizzi IP esistente allocato a Memorystore for Redis.

    • Devi fornire l'intervallo IP aggiuntivo quando abiliti le repliche di lettura per l'istanza Redis. Puoi scegliere un intervallo specifico o lasciare che Memorystore ne selezioni uno automaticamente.

  • L'indirizzo IP di lettura/scrittura dell'istanza non cambia quando abiliti le repliche di lettura. L'indirizzo IP dell'endpoint di lettura si trova nell'intervallo originale allocato per l'istanza Memorystore, non nell'intervallo aggiuntivo fornito quando abiliti le repliche di lettura.

  • Per trovare il nuovo endpoint di lettura, visualizza le informazioni sulla replica di lettura per l'istanza dopo il completamento dell'operazione per abilitare le repliche di lettura.

Scalabilità di un'istanza

Puoi scalare il numero di repliche di lettura per l'istanza e puoi anche modificare le dimensioni dei nodi:

Ti consigliamo di scalare l'istanza durante un periodo di traffico di lettura e scrittura ridotto per ridurre al minimo l'impatto sull'applicazione.

L'aggiunta di una nuova replica comporta un carico aggiuntivo sulla replica principale mentre esegue una sincronizzazione completa. Quando aggiungi nodi, le connessioni esistenti non vengono interessate o trasferite. Una volta disponibile, la nuova replica inizia a ricevere connessioni dall'endpoint e gestisce le letture. La rimozione di una replica chiude tutte le connessioni attive indirizzate a quella replica. L'applicazione client deve essere configurata in modo da riconnettersi automaticamente all'endpoint di lettura per ristabilire le connessioni alle repliche rimanenti.

Best practice

Gestione della memoria

Redis non consente alle scritture client di superare il limite maxmemory dell'istanza. Tuttavia, l'overhead come la frammentazione, i buffer di replica e i comandi costosi come EVAL possono aumentare l'utilizzo della memoria oltre questo limite. In questi casi, Memorystore non riesce a scrivere finché la pressione sulla memoria non viene ridotta. Per maggiori dettagli, consulta le best practice di gestione della memoria.

Se Memorystore è in fase di operazione BGSAVE a causa di un'esportazione o di una replica di sincronizzazione completa e si verifica una condizione di esaurimento della memoria, il processo secondario viene terminato. In questo caso, l'operazione BGSAVE non va a buon fine e il server nodo Redis rimane disponibile.

Per garantire la replica e la creazione di snapshot in tutte le circostanze, ti consigliamo di mantenere l'utilizzo della memoria al di sotto del 50% durante operazioni importanti come l'esportazione, la scalabilità e così via. Puoi attivare manualmente l'esportazione o il failover per vedere l'impatto di queste operazioni sulle prestazioni.

Gestione della CPU

Memorystore fornisce metriche sull'utilizzo della CPU e sul numero di connessioni per ogni nodo. Ti consigliamo di allocare un overhead sufficiente per tollerare la perdita di una singola zona di disponibilità. Il target ideale può variare in base al numero di repliche e ai pattern di utilizzo, ma un buon punto di partenza è mantenere l'utilizzo della CPU delle repliche al di sotto del 50%.

I singoli nodi potrebbero registrare un utilizzo elevato se i pattern di utilizzo dei client non sono bilanciati o se le operazioni di failover comportano una distribuzione delle connessioni non bilanciata. In questo caso, ti consigliamo di chiudere periodicamente le connessioni per consentire a Memorystore di riequilibrarle automaticamente. Memorystore non ribilancia le connessioni aperte.

Gestione del bilanciamento delle connessioni

Ogni volta che le connessioni di un nodo vengono chiuse, i client devono riconnettersi, in genere abilitando la riconnessione automatica nella libreria client scelta. Quando il nodo viene reintrodotto, le connessioni esistenti non vengono reindirizzate, ma le nuove connessioni vengono indirizzate al nuovo nodo. I client possono interrompere periodicamente le connessioni per assicurarsi che siano bilanciate tra i nodi disponibili.

Gestione del ritardo della replica

È possibile che le repliche rimangano indietro, soprattutto quando la frequenza di scrittura è molto elevata. In questi scenari, la replica continua a essere disponibile per le letture. In questo caso, le letture dalla replica possono essere obsolete e l'applicazione deve essere in grado di gestire questa situazione oppure deve essere risolto il problema della frequenza di scrittura elevata.

Abilita le repliche di lettura su un'istanza esistente

Prima di abilitare le repliche di lettura su un'istanza Memorystore for Redis esistente, ti consigliamo vivamente di ridurre il traffico di scrittura verso il nodo principale. In questo modo, il nodo principale può sincronizzare completamente i dati con le repliche. Se non riduci il traffico di scrittura, potresti non essere in grado di abilitare le repliche di lettura.

Passaggi successivi