Questa pagina descrive come i dati vengono replicati in Spanner, i diversi tipi di repliche di Spanner e i relativi ruoli nelle letture e scritture e i vantaggi della replica.
Panoramica
Spanner replica automaticamente a livello di byte. Come descritto in La durata delle letture e delle scritture Spanner, sfrutta questa funzionalità nel file system sottostante su cui è basato. Spanner scrive le mutazioni del database nei file in questo file system e il file system si occupa di replicare e recuperare i file in caso di errore di una macchina o di un disco.
Anche se il file system distribuito sottostante su cui si basa Spanner già fornisce la replica a livello di byte, Spanner replica anche i dati per offrire i vantaggi aggiuntivi della disponibilità dei dati e della località geografica. A livello generale, tutti i dati in Spanner sono organizzati in righe. Spanner crea più copie, o "repliche," di queste righe e le archivia in diverse aree geografiche. Spanner utilizza uno schema di replica sincrono basato su Paxos, in cui le repliche di voto prendono un voto per ogni richiesta di scrittura prima del commit della scrittura. Questa proprietà della replica sincrona globale consente di leggere i dati più aggiornati da qualsiasi replica di lettura e scrittura o di sola lettura di Spanner.
Spanner crea repliche di ogni suddiviso di database. Una suddivisione contiene un intervallo di righe contigue, in cui le righe sono ordinate per chiave primaria. Tutti i dati di una suddivisione sono fisicamente archiviati insieme nella replica e Spanner gestisce ogni replica da una zona di errore indipendente. Per saperne di più, consulta Informazioni sugli schemi.
Un insieme di suddivisioni viene archiviato e replicato utilizzando Paxos. All'interno di ogni set di repliche Paxos, viene scelta una replica come leader. Le repliche leader sono responsabili della gestione delle scritture, mentre qualsiasi replica di lettura/scrittura o di sola lettura può soddisfare una richiesta di lettura senza comunicare con la leader. Tuttavia, se viene richiesta una lettura elevata, in genere la replica leader viene consultata per garantire che la replica di sola lettura abbia ricevuto tutte le mutazioni recenti.
Vantaggi della replica di Spanner
I vantaggi della replica di Spanner includono:
Disponibilità dei dati: avere più copie dei tuoi dati rende i dati più disponibili per i clienti che vogliono leggerli. Inoltre, Spanner può continuare a gestire le scritture anche se alcune repliche non sono disponibili, perché è necessaria solo la maggior parte delle repliche di voto per eseguire il commit di una scrittura.
Località geografica: grazie alla possibilità di posizionare i dati in diverse regioni e continenti con Spanner, i dati possono essere geograficamente più vicini e, di conseguenza, più rapidi da accedere agli utenti e ai servizi che ne hanno bisogno.
Esperienza su un singolo database: Spanner può offrire un'esperienza unica per il database grazie alla replica sincrona e all'elevata coerenza globale.
Sviluppo delle applicazioni semplificato: poiché Spanner è conforme ad ACID e offre un'elevata coerenza globale, gli sviluppatori che lavorano con Spanner non devono aggiungere ulteriore logica nelle proprie applicazioni per gestire la coerenza finale, rendendo lo sviluppo delle applicazioni e la successiva manutenzione più semplici e veloci.
Tipi di replica
Spanner ha tre tipi di repliche: repliche di lettura e scrittura, repliche di sola lettura e repliche di testimonianza. Le regioni e le topologie di replica che formano le configurazioni delle istanze di base sono fisse. Le configurazioni di base delle istanze a livello di regione utilizzano solo repliche di lettura e scrittura. Le configurazioni di base delle istanze a due regioni utilizzano repliche di lettura e scrittura e di testimonianza, mentre le configurazioni di istanze di base multiregionali utilizzano una combinazione di tutti e tre i tipi di replica. Puoi creare configurazioni di istanze personalizzate e aggiungere ulteriori repliche di sola lettura per le configurazioni di istanze a livello di una o più regioni.
La tabella seguente riassume i tipi di repliche Spanner e le relative proprietà:
| Tipo di replica | Può votare | Può diventare leader | Può pubblicare letture | Può configurare la replica manualmente |
|---|---|---|---|---|
| Lettura/scrittura | sì | sì | sì | no |
| Sola lettura | no | no | sì | Sì* |
| Testimone | sì | no | no | no |
* Per saperne di più, scopri come creare un'istanza con una configurazione personalizzata dell'istanza.
Repliche di lettura/scrittura
Le repliche di lettura e scrittura supportano sia le letture sia le scritture. Queste repliche:
- Conserva una copia completa dei tuoi dati.
- Elabora le letture.
- Può votare se eseguire una scrittura.
- Partecipare alle elezioni della leadership.
- Sono idonei a diventare leader.
- Sono l'unico tipo utilizzato nelle istanze a regione singola.
Repliche di sola lettura
Le repliche di sola lettura supportano solo le letture, non le scritture. Queste repliche non consentono di votare per leader o per impegnare scritture, quindi ti consentono di scalare la capacità di lettura senza aumentare il quorum necessario per le scritture. Replica di sola lettura:
- Conserva una copia completa dei tuoi dati, che viene replicata dalle repliche di lettura e scrittura.
- Elabora le letture.
- Non partecipare alle votazioni per impegnare le scritture. Di conseguenza, la posizione delle repliche di sola lettura non contribuisce mai alla latenza di scrittura.
Se si tratta della replica più vicina alla tua applicazione, la replica di sola lettura può generalmente gestire letture inattive senza bisogno di un round trip alla regione leader predefinita, supponendo che l'inattività sia di almeno 15 secondi. Puoi anche utilizzare letture dirette per instradare le transazioni di sola lettura e le singole letture a una regione o a un tipo di replica specifico in una configurazione di istanze multiregionali. Per ulteriori informazioni, consulta la sezione Letture dirette.
Letture efficaci potrebbero richiedere un viaggio di andata e ritorno alla replica leader. Il round trip serve solo per negoziare il timestamp, non per spedire i dati effettivi dal responsabile. La negoziazione del timestamp è un'operazione efficiente dalla CPU presso il responsabile e in genere i dati sono già in fase di elaborazione. Questa comunicazione viene gestita automaticamente dal sistema.
Per ulteriori informazioni sulle letture inattive ed efficaci, consulta la sezione In letture.
Non sono idonei a diventare leader.
Puoi creare una configurazione personalizzata di istanze a livello di regione o più regioni e aggiungere repliche facoltative di sola lettura per scalare le letture e supportare le letture inattive a bassa latenza. Puoi aggiungere le località elencate in Regione facoltativa come replica di sola lettura facoltativa. Se non vedi la località che hai scelto per la replica di sola lettura, puoi richiedere una nuova regione di replica di sola lettura facoltativa. Tieni presente che non puoi modificare la topologia di replica delle configurazioni delle istanze di base, che sono fisse.
Tutte le repliche facoltative di sola lettura sono soggette a costo di calcolo e costi di archiviazione. Inoltre, l'aggiunta di repliche di sola lettura a una configurazione dell'istanza personalizzata non modifica gli SLA di Spanner della configurazione dell'istanza. Se scegli di aggiungere una replica di sola lettura a un continente che si trova in un continente diverso da quello dell'regione leader, ti consigliamo di aggiungere almeno due repliche di sola lettura. Ciò consente di mantenere una bassa latenza di lettura nel caso in cui una delle repliche di sola lettura non sia disponibile.
Quando aggiungi repliche di sola lettura, la replica leader subisce un carico maggiore di repliche, il che potrebbe influire sulle prestazioni. Come best practice, testa prima i carichi di lavoro delle prestazioni in istanze non di produzione nella configurazione dell'istanza personalizzata. Puoi fare riferimento alla dashboard del benchmark per la latenza e la velocità effettiva tra regioni per i dati di latenza mediani tra regioni. Ad esempio, se crei una configurazione di istanza personalizzata con la configurazione di base per più regioni eur6 e una replica facoltativa di sola lettura in us-east1, l'elevata latenza di lettura prevista per un client in us-east1 è di circa 100 millisecondi a causa del tempo di round trip alla regione leader in europe-west4. Le letture inattive con un livello di inattività sufficientemente elevato non
rispettano il round trip e sono quindi molto più veloci. Puoi anche utilizzare la metrica Latenza per tipo di transazione per visualizzare i dati di latenza per le transazioni di tipo lettura-scrittura e sola lettura.
Per le istruzioni, vedi Creare una configurazione dell'istanza personalizzata.
Repliche testimoni
Le repliche dei testimoni non supportano le letture, ma partecipano alle votazioni per impegnare le scritture. Queste repliche consentono di raggiungere più facilmente i quorum per le scritture senza le risorse di archiviazione e calcolo necessarie dalle repliche di lettura e scrittura per archiviare una copia completa dei dati e gestire le letture. Repliche replica:
- Vengono utilizzate solo in istanze multiregionali.
- Non conservare una copia completa dei dati.
- Non pubblicare letture.
- Vota se eseguire il commit delle scritture.
- Partecipare alle elezioni leader, ma non avere l'idoneità a diventare leader.
Il ruolo delle repliche nelle scritture e nelle letture
Questa sezione descrive il ruolo delle repliche nelle scritture e nelle letture di Spanner, il che è utile per capire perché Spanner utilizza le repliche di testimonianza nelle configurazioni multiregionali.
In scrittura
Le richieste di scrittura del client vengono sempre elaborate per prime nella replica leader, anche se esiste una replica non leader più vicina al client o se la replica leader è geograficamente distante dal client. Se utilizzi una configurazione dell'istanza multiregionale e l'applicazione client si trova in una regione non leader, Spanner utilizza il routing leader-aware per instradare le transazioni di lettura e scrittura in modo dinamico, in modo da ridurre la latenza nel database. Per ulteriori informazioni, vedi Routing sensibile al lead.
La replica leader registra la scrittura in arrivo e la inoltra, in parallelo, alle altre repliche idonee a votare per quella scrittura. Ogni replica idonea completa la propria scrittura, quindi risponde al leader con un voto per decidere se eseguire o meno la scrittura. La scrittura viene commessa quando la maggioranza delle repliche di voto (o "quorum") accetta di commettere la scrittura. In background, tutte le repliche rimanenti (non testimoni) registrano la scrittura. Se una replica di lettura/scrittura o di sola lettura rimane in ritardo sulle scritture di logging, può richiedere ai dati mancanti di un'altra replica di disporre di una copia completa e aggiornata dei dati.
Nelle letture
Le richieste di lettura del client potrebbero essere eseguite o richiedere la comunicazione con la replica leader, a seconda della modalità di contemporaneità della richiesta di lettura.
Le letture che fanno parte di una transazione di lettura-scrittura vengono gestite dalla replica leader, poiché la replica leader mantiene i blocchi necessari per applicare la serializzabilità.
I metodi di lettura singola (una lettura al di fuori del contesto di una transazione) e le letture nelle transazioni di sola lettura potrebbero richiedere la comunicazione con la leader, a seconda della modalità di contemporaneità della lettura. Scopri di più su queste modalità di contemporaneità in Tipi di lettura.
Le richieste di lettura efficaci possono andare a qualsiasi replica di lettura/scrittura o di sola lettura. Se la richiesta va a una replica non leader, questa deve comunicare con il responsabile per eseguire la lettura.
Le richieste di lettura inattive vanno alla replica di sola lettura o lettura/scrittura più vicina disponibile che viene raggiunta fino al timestamp della richiesta. Può essere la replica leader se quella leader è la più vicina al client che ha emesso la richiesta di lettura.