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à del livello Redis di Memorystore.

Le repliche di lettura ti consentono di scalare il tuo 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 la sezione Scalabilità delle letture con l'endpoint di lettura.

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

Casi d'uso per le repliche di lettura

L'archiviazione di sessioni, le classifiche, il motore per suggerimenti e altri casi d'uso richiedono un'alta disponibilità. Per questi casi d'uso ci sono molti più volti di scritture e questi casi d'uso sono in genere in grado di tollerare alcuni articoli obsoleti. In casi come questi, è opportuno sfruttare le repliche di lettura per aumentare la disponibilità e la scalabilità dell'istanza.

Comportamento di lettura delle repliche

  • Le repliche di lettura non sono abilitate sulle istanze del livello Standard per impostazione predefinita.
  • Una volta abilitate le repliche di lettura su un'istanza, non è più possibile disabilitare le repliche di lettura per tale istanza.
  • Le istanze del 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 sulle istanze che utilizzano Redis versione 5.0 o 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. In seguito, 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 a /28 o superiore. Le dimensioni più ampie 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, specifichi il numero di repliche che vuoi nell'istanza. Memorystore distribuisce automaticamente i nodi di replica primaria e di lettura tra le zone disponibili in un'area geografica.

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

Il servizio di monitoraggio dell'integrità di Memorystore for Redis monitora l'istanza ed è responsabile di rilevare eventuali errori del nodo primario ed sceglie una replica come nuovo primario e avvia un failover automatico nella nuova istanza principale.

Failover per istanze con repliche di lettura

In caso di errore di un'istanza principale, il servizio di monitoraggio dell'integrità Memorystore avvia il failover e la nuova istanza principale viene resa disponibile sia per le operazioni di lettura che di scrittura. 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 principale, ma tutte le connessioni client all'endpoint principale vengono disconnesse durante un failover. Le applicazioni con la logica dei nuovi tentativi di connessione si riconnettono automaticamente quando la nuova istanza principale è online. Alcune delle connessioni client all'endpoint di lettura subiscono anche disconnessioni dalla replica di lettura promossa a primaria durante il failover. Le connessioni alle repliche rimanenti continuano a essere pubblicate 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 tempi di replica diversi. Tuttavia, il processo di failover fa il possibile per eseguire il failover della replica con il ritardo minimo. Ciò consente di ridurre al minimo la quantità di perdita di dati e la riduzione della velocità effettiva di lettura durante un failover. L'istanza principale appena promossa può trovarsi nella stessa zona o in una zona diversa dell'ex principale. Viene selezionata una replica come nuova principale se si trova nella stessa zona dell'ex principale e presenta il ritardo minimo. In caso contrario, una replica da una zona diversa può diventare la nuova istanza 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, potrebbero non essere salvate alcune scritture per l'istanza. 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ò avvenire in scenari rari. La sincronizzazione completa può richiedere da alcuni 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 la lettura. 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 verificarsi in vari errori e in condizioni non integre che interessano l'applicazione. Il comportamento varia a seconda che l'istanza abbia una replica o due o più repliche. La sezione definisce alcune modalità di errore comuni e il comportamento dell'istanza durante queste condizioni.

La replica non è disponibile

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

  • In caso di esaurimento delle risorse di Compute Engine o errore della zona, la replica non viene ripristinata finché la condizione non viene risolta.

Errore zona

  • Se la zona in cui si trova l'istanza principale non riesce, l'istanza principale viene automaticamente trasferita in una replica in un'altra zona. Se l'istanza ha una sola replica, l'endpoint di lettura non sarà disponibile per 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 trova una o più repliche non va a buon fine, le repliche non sono disponibili per 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 ritardo minimo nelle zone rimanenti viene promossa all'istanza 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 rimangono in esecuzione, 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 pubblicare scritture. In caso di partizione di rete, tutte le primarie in una partizione di minoranza si autorestringono. La partizione di maggioranza (se esistente) sceglie una nuova istanza principale se non ne ha già una. Le repliche isolate continuano a gestire le letture. Tuttavia, possono diventare inattive se non possono essere sincronizzate dall'istanza principale.

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

Stock

Occasionalmente, le risorse Compute Engine necessarie per Memorystore non sono disponibili in una zona, il che comporta un esaurimento. Se è presente un blocco in una regione in cui provi a eseguire il provisioning di un'istanza, l'operazione per creare l'istanza non riesce.

Sincronizzazione completa

Quando una replica è troppo indietro rispetto a quella primaria, attiva una sincronizzazione completa che copia un'intera istantanea da quella principale a una replica. Questa operazione può richiedere da qualche minuto a un'ora nel peggiore dei casi. La sincronizzazione completa non causa un errore dell'istanza, ma durante questo periodo la replica in esecuzione non è disponibile per le letture e l'utilizzo principale della CPU e della memoria da parte dell'istanza principale.

L'endpoint principale restituisce READONLY

Le tue 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 attuabili o il comportamento persiste, contatta il team di assistenza di Google Cloud.

Scalabilità delle letture con l'endpoint di lettura

Le repliche di lettura consentono alle applicazioni di scalare le loro letture leggendo le 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 l'applicazione. e bilancia in modo uniforme le connessioni tra le repliche nell'istanza. Le connessioni alla replica di lettura possono inviare query di lettura, ma non scrivere query. Ogni istanza del livello Standard con repliche di lettura abilitate ha un endpoint di lettura. Per istruzioni sulla visualizzazione dell'endpoint di lettura dell'istanza, vedi Visualizzare 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 sono indirizzate all'istanza principale.
  • Una replica è considerata disponibile purché sia in grado di gestire il traffico dei client. Non sono inclusi i momenti 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 volume di scrittura elevato possono leggere dati inattivi da una replica che serve scritture elevate.
  • Nel caso in cui un nodo di replica diventi il principale, le connessioni a tale nodo vengono terminate e le nuove connessioni vengono reindirizzate a un nuovo nodo di replica.
  • Le singole connessioni all'endpoint di lettura scelgono 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.

Lettura della coerenza

Le repliche di lettura vengono mantenute utilizzando la replica asincrona di OSS Redis. A causa della natura della replica asincrona, è possibile che la replica sia in ritardo rispetto a quella principale. Le applicazioni con scritture costanti che sono anche in lettura dalla replica dovrebbero essere in grado di tollerare letture incoerenti.

Se l'applicazione richiede la lettura della coerenza, ti consigliamo di utilizzare l'endpoint principale sia per le scritture che per le letture. L'utilizzo dell'endpoint principale assicura che le letture siano sempre indirizzate all'istanza principale. Anche in questo caso è possibile che il sito abbia operazioni di lettura inattive dopo un failover.

L'impostazione di TTL sulle chiavi dell'istanza principale garantisce che le chiavi scadute non vengano lette da quest'ultima o dalla replica. Questo perché Redis garantisce che non sia possibile leggere una chiave scaduta dalla replica.

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

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

  • Per abilitare le repliche di lettura su un'istanza Redis esistente, devi allocare un intervallo di indirizzi IP aggiuntivo 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 abiliti le repliche di lettura per l'istanza Redis. Puoi scegliere un intervallo specifico o lasciare che l'archivio di memoria ne selezioni automaticamente uno.

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

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

Scalabilità di un'istanza

Puoi scalare il numero di repliche di lettura per la tua istanza e puoi anche modificare le dimensioni del nodo:

Ti consigliamo di scalare l'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. L'aggiunta di nodi non influisce sulle connessioni esistenti o su quelle che vengono trasferite. Quando la nuova replica è disponibile inizia a ricevere connessioni dall'endpoint e gestisce le letture. La rimozione di una replica chiude tutte le connessioni attive indirizzate a tale 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 di maxmemory dell'istanza. Tuttavia, i costi generali 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 per la gestione della memoria.

Se Memorystore è in esecuzione su un'operazione BGSAVE a causa di un'esportazione o di una replica di sincronizzazione completa e si verifica una condizione OOM, il processo secondario viene interrotto. In questo caso l'operazione BGSAVE ha esito negativo e il server nodo Redis rimane disponibile.

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

Gestione della CPU

Memorystore fornisce metriche sull'utilizzo della CPU e sul numero di connessioni per ciascun nodo. Ti consigliamo di allocare un carico sufficiente, in modo che la perdita di una singola zona di disponibilità possa essere tollerata. Ciò significa che dovresti mantenere l'utilizzo della CPU delle repliche pari o inferiore al 50%. In questo modo, se una delle tre zone non è disponibile, le repliche rimanenti vengono eseguite al 75%.

I singoli nodi potrebbero riscontrare un utilizzo elevato se i pattern di utilizzo del client non sono bilanciati o se le operazioni di failover determinano una distribuzione della connessione non bilanciata. In questo caso, ti consigliamo di chiudere periodicamente i collegamenti per consentire a Memorystore di ribilanciare automaticamente le connessioni. Memorystore non ribilancia il bilanciamento delle connessioni aperte.

Gestione saldo saldo

Ogni volta che le connessioni di un nodo sono chiuse, i client devono riconnettersi, generalmente attivando la riconnessione automatica nella libreria client di tua scelta. Quando il nodo viene reintrodotto, le connessioni esistenti non vengono reindirizzate, ma le nuove connessioni vengono instradate al nuovo nodo. I client possono interrompere periodicamente le connessioni per garantire l'equilibrio tra i nodi disponibili.

Gestione dei tempi di replica

È possibile che le repliche siano in ritardo, soprattutto quando la frequenza di scrittura è molto elevata. In questi casi, la replica continua a essere disponibile per le letture. In questa circostanza, le letture dalla replica possono essere obsolete e l'applicazione dovrebbe essere in grado di gestire questo aspetto, altrimenti la frequenza di scrittura elevata dovrebbe essere affrontata.

Passaggi successivi