Informazioni sulle repliche di lettura

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

Le repliche di lettura 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 saperne di più, consulta Scalabilità delle letture con l'endpoint di lettura.

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

Casi d'uso per le repliche di lettura

Lo store di sessioni, la leaderboard, il motore per suggerimenti e altri casi d'uso richiedono che l'istanza sia ad alta disponibilità. Per questi casi d'uso ci sono molte più letture che scritture e solitamente tollerano alcune letture obsolete. In questi casi, ha senso 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 sulle istanze di livello Standard per impostazione predefinita.
  • Una volta abilitate le repliche di lettura 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 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 5.0 o versioni successive.
  • Se definisci una zona e una zona alternativa per il provisioning dei nodi, Memorystore utilizza queste zone per il primo e il secondo nodo nell'istanza. Dopodiché, 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. Dimensioni di intervalli più grandi, come /27 e /26, sono valide. Gli intervalli più piccoli come /29 non sono supportati per questa funzionalità.

Architettura

Quando Abilita le repliche di lettura, specifichi il numero di repliche che vuoi inserire nell'istanza. Memorystore distribuisce automaticamente i nodi di replica principali e di lettura tra le zone disponibili in una regione.

Ogni istanza ha un endpoint primario e un endpoint di lettura. L'endpoint primario indirizza sempre il traffico al nodo primario, mentre l'endpoint di lettura bilancia automaticamente il carico delle query di lettura tra le repliche disponibili.

Il servizio di monitoraggio dell'integrità di Memorystore for Redis monitora l'istanza ed è responsabile di rilevare eventuali errori del nodo principale, seleziona una replica come nuova istanza primaria e avvia un failover automatico a quello principale.

Failover per le istanze con repliche di lettura

In caso di errore di un'origine primaria, il servizio di monitoraggio dello stato di integrità Memorystore avvia il failover e la nuova risorsa primaria viene resa disponibile per le operazioni di lettura e scrittura. Il failover solitamente viene completato in meno di 30 secondi.

Quando si verifica un failover, l'endpoint primario reindirizza automaticamente il traffico al nuovo primario. Tuttavia, tutte le connessioni client all'endpoint primario vengono disconnesse durante un failover. Le applicazioni con logica di nuovo tentativo di connessione si riconnetteranno automaticamente quando la nuova connessione principale sarà online. Alcune connessioni client all'endpoint di lettura vengono disconnesse anche dalla replica di lettura 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 il possibile per eseguire il failover sulla replica con il ritardo minimo. Ciò consente di ridurre al minimo la perdita di dati e la riduzione della velocità effettiva di lettura durante un failover. Quella principale appena promossa può trovarsi nella stessa zona o in un'altra zona della precedente. Una replica viene selezionata come nuova principale se si trova nella stessa zona della precedente e ha il ritardo minimo. In caso contrario, una replica da una zona diversa può diventare la nuova principale.

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

Redis fa il possibile per evitare le altre repliche che richiedono una sincronizzazione completa durante il failover, ma può accadere in rari casi. Una sincronizzazione completa può richiedere da pochi minuti a un'ora, a seconda della velocità di scrittura e delle dimensioni del set di dati che viene replicato. 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 incorrere in vari errori e condizioni non integri che influiscono sull'applicazione. Il comportamento varia a seconda che l'istanza abbia una o due o più repliche. La sezione descrive alcune modalità di errore comuni e il comportamento dell'istanza durante queste condizioni.

La replica non è disponibile

  • Quando per qualsiasi motivo una replica si arresta, 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 instradate alla replica ripristinata. Il tempo per ripristinare una replica varia a seconda della modalità di errore.

  • In caso di esaurimento scorte o di errore di una zona di Compute Engine, la replica non viene ripristinata fino alla risoluzione della condizione.

Errore zona

  • Se la zona in cui si trova quella principale ha esito negativo, quella principale esegue automaticamente il failover su una replica in un'altra zona. Se l'istanza ha una sola replica, l'endpoint di lettura non sarà disponibile per tutta la durata dell'interruzione della zona. Se l'istanza ha più di una replica, le repliche all'esterno della zona interessata sono disponibili per le letture

  • Se la zona in cui si trova una o più repliche non funziona, le repliche non saranno disponibili per tutta la durata dell'errore della zona. Se si verifica un errore di due zone e sono presenti due o più repliche, la replica con il minor ritardo nelle zone rimanenti viene promossa a principale. Tutte 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 client, le zone o i nodi peer. Memorystore usa un sistema basato sul quorum per impedire ai nodi isolati di gestire le scritture. In caso di una partizione di rete, qualsiasi partizione primaria in una partizione di minoranza si retrocede. La partizione di maggioranza (se esistente) sceglie una nuova partizione principale se non ne ha già una. Le repliche isolate continuano a gestire le letture. Tuttavia, potrebbero diventare inattivi se non sono in grado di sincronizzarsi dall'origine dati principale.

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

Esaurito

A volte le risorse di Compute Engine necessarie per Memorystore non sono disponibili in una zona e questo determina un esaurimento scorte. Se è presente una disponibilità in una regione in cui provi a eseguire il provisioning di un'istanza, l'operazione per creare l'istanza non va a buon fine.

Sincronizzazione completa

Quando una replica si trova troppo indietro rispetto a quella principale, attiva una sincronizzazione completa che copia un intero snapshot dall'istanza principale a una replica. Questa operazione può richiedere da minuti 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'utilizzo principale di CPU e memoria risulta maggiore.

L'endpoint principale restituisce READONLY

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

Lettura della scalabilità con l'endpoint di lettura

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

Lettura endpoint

L'endpoint di lettura è un indirizzo IP a cui si connette l'applicazione. Bilancia in modo uniforme il carico delle connessioni tra le repliche dell'istanza. Le connessioni alla replica di lettura possono inviare query di lettura, ma non query di scrittura. Ogni istanza del livello Standard in cui sono abilitate delle repliche di lettura dispone di un endpoint di lettura. Per istruzioni sulla visualizzazione dell'endpoint di lettura dell'istanza, vedi Visualizzazione delle 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 al principale.
  • Una replica è considerata disponibile purché sia in grado di gestire il traffico client. Non sono inclusi i casi in cui una replica è in fase di sincronizzazione completa con l'istanza principale.
  • Una replica con un ritardo di replica elevato continua a gestire il traffico. Le applicazioni con volumi di scrittura elevati possono leggere dati inattivi da una replica che gestisce un numero elevato di scritture.
  • Se un nodo di replica diventa il principale, le connessioni a questo nodo vengono terminate e le nuove connessioni vengono reindirizzate su un nuovo nodo di replica.
  • Le singole connessioni all'endpoint di lettura hanno come target la stessa replica per l'intera durata della connessione. Non è garantito che le diverse connessioni dello stesso host client abbiano come target lo stesso nodo di replica.

Coerenza di lettura

Le repliche di lettura vengono gestite utilizzando la replica asincrona del sistema operativo Redis nativo. A causa della natura della replica asincrona, è possibile che la replica sia in ritardo rispetto all'istanza principale. Le applicazioni con scritture costanti che leggono dalla replica dovrebbero essere in grado di tollerare letture incoerenti.

Se l'applicazione richiede coerenza in fase di scrittura, consigliamo di utilizzare l'endpoint principale sia per le scritture che per le letture. L'utilizzo dell'endpoint primario garantisce che le letture siano sempre indirizzate a quello primario. Anche in questo caso è possibile avere letture inattive dopo un failover.

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

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

  • L'abilitazione delle repliche di lettura su un'istanza Redis esistente è un'operazione esclusiva, ovvero non puoi apportare altre modifiche all'istanza di operazione di aggiornamento nell'ambito della stessa operazione che abilita le repliche di lettura.

  • L'abilitazione delle repliche di lettura su un'istanza Redis esistente richiede l'allocazione di un ulteriore intervallo di indirizzi IP valido di dimensione /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 per la tua 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 di Memorystore, non nell'intervallo aggiuntivo che fornisci durante l'abilitazione delle repliche di lettura.

  • Per trovare il nuovo endpoint di lettura, visualizza le informazioni sulle repliche di lettura per la tua 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 anche modificare la dimensione del nodo:

Ti consigliamo di scalare l'istanza in un periodo di traffico ridotto in 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. Le connessioni esistenti non sono interessate o trasferite. Quando è disponibile, la nuova replica inizia a ricevere le connessioni dall'endpoint e gestisce le letture. La rimozione di una replica chiude tutte le connessioni attive instradate 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 del client di superare il limite maxmemory dell'istanza. Tuttavia, overhead come frammentazione, buffer di replica e comandi costosi come EVAL possono aumentare l'utilizzo della memoria oltre questo limite. In questi casi Memorystore non riesce a eseguire le scritture finché non si riduce la pressione della memoria. Per ulteriori dettagli, consulta le best practice per la gestione della memoria.

Se Memorystore è in corso di un'operazione BGSave a causa di un'esportazione o di una replica di sincronizzazione completa e si verifica una condizione OOM, il processo figlio viene arrestato. In questo caso l'operazione BGSALVA 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 inferiore al 50% durante operazioni importanti come esportazione, 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 delle connessioni per ogni nodo. Ti consigliamo di assegnare un overhead sufficiente da 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 possono subire un utilizzo elevato se i pattern di utilizzo dei client non sono bilanciati o se le operazioni di failover comportano una distribuzione di connessioni non bilanciata. In questo caso, ti consigliamo di chiudere periodicamente le connessioni per consentire a Memorystore di ribilanciarle automaticamente. Memorystore non ribilancia le connessioni aperte.

Gestione del saldo delle connessioni

Ogni volta che le connessioni di un nodo sono chiuse, i client devono riconnettersi, in genere abilitando la riconnessione automatica nella libreria client che preferisci. Quando il nodo viene reintrodotto, le connessioni esistenti non vengono reindirizzate, ma le nuove connessioni vengono instradate al nuovo nodo. I client possono terminare periodicamente le connessioni per garantirne il bilanciamento tra i nodi disponibili.

Gestione del tempo di 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 dovrebbe essere in grado di gestirle oppure l'alta frequenza di scrittura deve essere gestita.

Passaggi successivi