Informazioni sulle repliche di lettura

Il livello Standard di Memorystore for Redis consente 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 Redis di Memorystore.

Le repliche di lettura ti consentono di scalare il carico di lavoro di lettura eseguendo query sulle repliche. Viene fornito un endpoint di lettura per consentire alle applicazioni di distribuire più facilmente le query tra le repliche. Per ulteriori informazioni, consulta Eseguire il ridimensionamento delle letture con l'endpoint di lettura.

Per istruzioni su come gestire un'istanza Redis con repliche di lettura, consulta Gestire le repliche di lettura.

Casi d'uso per le repliche di lettura

Il negozio delle sessioni, la classifica, il sistema di raccomandazione e altri casi d'uso richiedono che l'istanza sia altamente disponibile. Per questi casi d'uso, le letture sono molto più numerose delle scritture e in genere sono in grado di tollerare alcune letture non aggiornate. In questi casi, ha senso utilizzare le repliche di lettura per aumentare la disponibilità e la scalabilità dell'istanza.

Comportamento della replica di lettura

  • Per impostazione predefinita, le repliche di lettura non sono abilitate nelle istanze di livello standard.
  • 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 unico endpoint per la distribuzione delle query tra i nodi replica.
  • Le repliche di lettura vengono mantenute utilizzando la replica asincrona di Redis.

Limitazioni e avvertenze

  • Le repliche di lettura sono supportate solo per le dimensioni delle istanze con nodi >= 5 GB.
  • Le repliche di lettura possono essere attivate solo sulle istanze che utilizzano Redis 5.0 o versioni successive.
  • Se designi una zona e una zona alternativa per il provisioning dei nodi, Memorystore utilizza queste zone per il primo e il secondo nodo dell'istanza. Dopodiché, Memorystore seleziona le zone per tutti gli altri nodi di cui è stato eseguito il provisioning per l'istanza.
  • Devi eseguire il provisioning dell'istanza con un intervallo di indirizzi IP CIDR di /28 o superiore. Sono validi intervalli di dimensioni maggiori, come /27 e /26. Gli intervalli più piccoli come /29 non sono supportati per questa funzionalità.

Architettura

Quando attivi le repliche di lettura, specifica il numero di repliche che vuoi nell'istanza. Memorystore distribuisce automaticamente i nodi principali e delle repliche di lettura tra le zone disponibili in una regione.

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 esegue il bilanciamento automatico del carico delle query di lettura tra le repliche disponibili.

Il servizio di monitoraggio dello stato di Memorystore per Redis monitora l'istanza ed è responsabile del rilevamento di eventuali errori del nodo principale, nonché dell'elezione di una replica come nuova principale e dell'avvio di un failover automatico alla nuova principale.

Failover per le istanze con repliche di lettura

Quando un database principale non funziona, il servizio di monitoraggio dell'integrità di Memorystore avvia il failover e il nuovo database principale viene reso disponibile sia per le letture sia per le scritture. In genere, il failover viene completato in meno di 30 secondi.

Quando si verifica un failover, l'endpoint principale reindirizza automaticamente il traffico al nuovo endpoint principale. Tuttavia, tutte le connessioni dei client all'endpoint principale vengono disconnesse durante un failover. Le applicazioni con logica di ripetizione della connessione si ricollegheranno automaticamente quando il nuovo cluster principale sarà online. Alcune delle connessioni del client all'endpoint di lettura vengono disconnesse anche dalla replica di lettura che viene promossa a principale durante il failover. Le connessioni alle repliche rimanenti continuano a essere servite 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 minor ritardo. In questo modo si riduce al minimo la quantità di dati persi e la riduzione del throughput di lettura durante un failover. Il nuovo account principale può trovarsi nella stessa zona o in una zona diversa rispetto all'account principale precedente. Una replica viene selezionata come nuova principale se si trova nella stessa zona dell'istanza principale precedente e ha il tempo di latenza più basso. In caso contrario, una replica di un'altra zona può diventare la nuova principale.

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

Redis fa del suo meglio per evitare che le altre repliche richiedano una sincronizzazione completa durante il failover, ma può accadere in rari casi. Una sincronizzazione completa può richiedere da alcuni minuti a un'ora, a seconda della frequenza di scrittura e delle dimensioni del set di dati in fase di replica. Durante questo periodo, le repliche in fase di sincronizzazione completa non sono disponibili per le letture. Al termine della 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 non attive che influiscono sull'applicazione. Il comportamento varia a seconda che l'istanza abbia una replica o due o più repliche. La sezione illustra alcune modalità di errore comuni e il comportamento dell'istanza in queste condizioni.

La replica non è disponibile

  • Quando una replica non va a buon fine per qualsiasi motivo, viene contrassegnata come non disponibile e tutte le connessioni alla replica vengono interrotte dopo un determinato timeout. Una volta recuperata la replica, le nuove connessioni vengono inoltrate alla replica ripristinata. Il tempo necessario per recuperare una replica varia a seconda della modalità di errore.

  • In caso di esaurimento delle scorte o di errore nella zona Compute Engine, la replica non viene recuperata finché la condizione non viene risolta.

Errore zona

  • Se la zona in cui si trova l'istanza principale non è disponibile, l'istanza principale viene trasferita automaticamente a una replica in un'altra zona. Se l'istanza ha una sola replica, l'endpoint di lettura non è disponibile per tutta la durata dell'interruzione della zona. Se l'istanza ha più di una replica, le repliche al di fuori della zona interessata sono disponibili per le letture

  • Se la zona in cui si trovano una o più repliche non è disponibile, queste repliche non sono disponibili per tutta 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. Le repliche rimanenti nelle zone non interessate sono disponibili per le letture.

Partizione di rete

Una partizione di rete è uno scenario in cui i nodi rimangono in esecuzione, ma non possono raggiungere tutti i clienti, le zone o i nodi peer. Memorystore utilizza un sistema basato su quorum per impedire ai nodi isolati di eseguire le scritture. In caso di partizione della rete, qualsiasi principale in una partizione di minoranza viene declassato automaticamente. La partizione con la maggioranza (se esistente) elegge un nuovo principale se non ne ha già uno. Le repliche isolate continuano a eseguire letture. Tuttavia, potrebbero diventare inattivi se non possono essere sincronizzati dall'account principale.

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

Esaurimento scorte

A volte le risorse Compute Engine necessarie per Memorystore non sono disponibili in una zona, il che porta a un esaurimento delle scorte. Se non è disponibile un'istanza in una regione in cui provi a eseguire il provisioning, l'operazione di creazione non va a buon fine.

Sincronizzazione completa

Quando una replica è troppo indietro rispetto all'istanza principale, viene attivata una sincronizzazione completa che copia un intero snapshot dall'istanza principale a una replica. Questa operazione può richiedere da alcuni minuti fino a un'ora nel peggiore dei casi. Una sincronizzazione completa non causa un errore dell'istanza, ma durante questo periodo la replica in fase di sincronizzazione completa non è disponibile per le letture e l'istanza principale registra un utilizzo maggiore di CPU e memoria.

L'endpoint principale restituisce READONLY

Le scritture all'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ò attenuare il problema. Se queste opzioni non sono possibili o il comportamento persiste, contatta il Google Cloud team di assistenza.

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. Inoltre, bilancia uniformemente le connessioni 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 Visualizzare le informazioni sulla replica di lettura per l'istanza.

Comportamento dell'endpoint di lettura

  • L'endpoint di lettura distribuisce automaticamente le connessioni su tutte le repliche disponibili. Le connessioni non sono indirizzate all'account 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 principale.
  • Una replica con un ritardo di replica elevato continua a gestire il traffico. Le applicazioni con un volume elevato di scritture possono leggere dati non aggiornati da una replica che esegue un numero elevato di scritture.
  • Se un nodo replica diventa principale, le connessioni a quel nodo vengono terminate e le nuove connessioni vengono reindirizzate a un nuovo nodo replica.
  • Le singole connessioni all'endpoint di lettura hanno come target la stessa replica per tutta la durata della connessione. Non è garantito che connessioni diverse dallo stesso host client abbiano come target lo stesso nodo replica.

Coerenza di lettura

Le repliche di lettura vengono mantenute utilizzando la replica asincrona nativa di Redis OSS. A causa della natura della replica asincrona, è possibile che la replica rimanga indietro rispetto all'istanza 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 "leggi la tua scrittura", ti consigliamo di utilizzare l'endpoint principale sia per le scritture sia per le letture. L'utilizzo dell'endpoint principale garantisce che le letture siano sempre indirizzate all'endpoint principale. Anche in questo caso è possibile avere letture non aggiornate dopo un failover.

L'impostazione dei TTL per le chiavi nell'istanza principale garantisce che le chiavi scadute non vengano lette dall'istanza principale o dalla replica. Questo perché Redis garantisce che una chiave scaduta non possa essere letta dalla replica.

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

  • L'attivazione delle repliche di lettura in un'istanza Redis esistente è un'operazione esclusiva, il che significa che non puoi eseguire altre operazioni di aggiornamento delle modifiche dell'istanza nell'ambito della stessa operazione che attiva le repliche di lettura.

  • Per abilitare le repliche di lettura su un'istanza Redis esistente, devi allocare un ulteriore intervallo di indirizzi IP valido di dimensioni /28, indipendentemente dalle dimensioni dell'intervallo di indirizzi IP esistente allocato a Memorystore for Redis.

    • Devi fornire l'intervallo IP aggiuntivo quando attivi le repliche di lettura per l'istanza Redis. Puoi scegliere un intervallo specifico o lasciare che sia Memorystore a selezionarne uno automaticamente.

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

  • Per trovare il nuovo endpoint di lettura, visualizza le informazioni sulle repliche di lettura per la tua istanza al termine dell'operazione per attivare le repliche di lettura.

Scalabilità di un'istanza

Puoi scalare il numero di repliche di lettura per l'istanza e anche modificare le dimensioni del nodo:

Ti consigliamo di eseguire il ridimensionamento dell'istanza in un periodo di traffico ridotto di lettura e scrittura per ridurre al minimo l'impatto sull'applicazione.

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

Best practice

Gestione della memoria

Redis non consente alle scritture del client di superare il limite di maxmemory dell'istanza. Tuttavia, il sovraccarico, come la frammentazione, i buffer di replica e i comandi costosi come EVAL, può aumentare l'utilizzo della memoria oltre questo limite. In questi casi, le scritture di Memorystore non riescono finché la pressione sulla memoria non viene ridotta. Per ulteriori dettagli, consulta le best practice per la gestione della memoria.

Se Memorystore sta eseguendo un'operazione BGSAVE a causa di un'esportazione o di una replica di sincronizzazione completa e si verifica una condizione di OOM, 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 ogni circostanza, ti consigliamo di mantenere l'utilizzo della memoria inferiore al 50% durante operazioni importanti come esportazione, scalabilità e così via. Puoi attivare manualmente l'esportazione o il failover per vedere l'impatto sulle prestazioni di queste operazioni.

Gestione della CPU

Memorystore fornisce metriche sull'utilizzo della CPU e sul conteggio delle connessioni per ogni nodo. Ti consigliamo di allocare un overhead sufficiente per consentire la tolleranza della 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 sono sbilanciati o se le operazioni di failover comportano una distribuzione sbilanciata delle connessioni. 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 ricollegarsi, in genere attivando la ricollegamento automatico nella libreria client che preferisci. Quando il nodo viene reintegrato, le connessioni esistenti non vengono reindirizzate, ma le nuove connessioni vengono reindirizzate 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 questa situazione, le letture dalla replica possono essere obsolete e l'applicazione dovrebbe essere in grado di gestirle oppure è necessario risolvere il problema della frequenza di scrittura elevata.

Passaggi successivi