Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Replica i dati da Spanner a Spanner Omni

Questo documento descrive i pattern, i passaggi di configurazione e le indicazioni operative per la configurazione di topologie di ripristino di emergenza tra Spanner gestito suGoogle Cloud e Spanner Omni in un ambiente esterno come AWS o un data center on-premise.

Combinando lo streaming delle transazioni utilizzando le modifiche in tempo reale e la connettività di rete dedicata tramite Cross-Cloud Interconnect, puoi ottenere obiettivi di recovery point (RPO) e recovery time (RTO) bassi oltre i confini del cloud.

Panoramica dell'architettura

In una topologia di ripristino di emergenza cross-cloud, Spanner su Google Cloud funge da database primario e Spanner Omni funge da deployment in standby o sito di ripristino di emergenza secondario. Puoi replicare continuamente le modifiche transazionali utilizzando le modifiche in tempo reale.

La seguente tabella mette a confronto le funzionalità, i ruoli e i limiti operativi del database tra un deployment Spanner principale e un deployment Spanner Omni secondario su AWS.

Confronto tra i deployment di Spanner principale e Spanner Omni secondario
Funzionalità o dimensione	Sito principale: Spanner su Google Cloud	Sito secondario: Spanner Omni su AWS
Modello di deployment	Servizio completamente gestito su Google Cloud.	Software autogestito su AWS, come Amazon Elastic Compute Cloud (Amazon EC2) o Amazon Elastic Kubernetes Service (Amazon EKS).
Disponibilità garantita da SLA	Fino al 99,999% per le configurazioni multiregionali e al 99,99% per le configurazioni regionali. Per saperne di più, consulta lo SLA di Spanner.	Gestito dal cliente; dipende dall'infrastruttura e dalla topologia.
Modalità di replica	Replica sincrona basata su Paxos tra zone e regioni.	Change Data Capture (CDC) asincrono quasi in tempo reale utilizzando i flussi di modifiche.
Recovery Point Objective (RPO)	Praticamente pari a zero all'interno dell'istanza gestita.	Da meno di un secondo a secondi attraverso i confini del cloud, a seconda del throughput della pipeline e della latenza di rete.
Recovery Time Objective (RTO)	Failover automatico immediato tra le repliche.	Dipende dal runbook di DNS e cambio di traffico.
Livello di transito della rete	Peering di rete Virtual Private Cloud (VPC) o Cloud Interconnect.	Cross-Cloud Interconnect connesso ad AWS Direct Connect.
Target di archiviazione dei backup	Backup di Spanner gestiti da Google, che possono essere ripristinati solo in Spanner gestito.	Cloud Storage o Amazon Simple Storage Service (Amazon S3), che possono essere ripristinati solo in Spanner Omni.

Prima di iniziare

Prima di configurare la replica tra Spanner e Spanner Omni, assicurati che il tuo ambiente soddisfi questi requisiti:

Esegui il provisioning della capacità di destinazione corrispondente: dimensiona il deployment Spanner Omni di destinazione in modo che corrisponda alla capacità di I/O di CPU, memoria e spazio di archiviazione dell'istanza Spanner principale. Il sottodimensionamento del deployment può causare un ritardo della replica e impedire al cluster in standby di gestire i workload durante un failover. Per saperne di più, consulta i requisiti di sistema.
Sincronizza gli schemi del database e i dati di riferimento: crea il database e le tabelle di destinazione in Spanner Omni utilizzando lo stesso dialetto SQL, GoogleSQL o PostgreSQL, e le stesse definizioni di schema del database Spanner di origine. Poiché non puoi ripristinare un backup Spanner gestito in Spanner Omni, esporta i dati esistenti da Spanner in file Avro in Cloud Storage e importali in Spanner Omni. Per maggiori informazioni, consulta Schema e modello dei dati, Sviluppa con Spanner Omni, Esporta i database da Spanner ad Avro e Importa ed esporta i dati.
Stabilisci la connettività di rete privata: configura il routing di rete privata tra la tua rete VPC Google Cloud e il tuo ambiente esterno in modo che i worker di replica possano connettersi sia a Spanner sia all'endpoint gRPC Spanner Omni. Per saperne di più, consulta Scelta di un prodotto di connettività di rete e Accelera la replica con Cross-Cloud Interconnect.

Replica continua dei dati utilizzando modifiche in tempo reale

Per le applicazioni che richiedono la continuità aziendale cross-cloud, i flussi di modifiche in tempo reale di Spanner generano modifiche ai dati transazionali (operazioni INSERT, UPDATE e DELETE) nell'ordine dei timestamp di commit. Una pipeline di replica continua legge i record delle modifiche da Spanner su Google Cloud e li scrive nel tuo deployment Spanner Omni.

L'utilizzo delle modifiche in tempo reale per la replica cross-cloud offre i seguenti vantaggi:

Standby attivo-passivo: mantiene una replica warm su Spanner Omni pronta a gestire i workload quando avvii un failover.
Replica selettiva: puoi configurare le modifiche in tempo reale in modo che monitorino l'intero database o limitarne l'ambito a tabelle e colonne specifiche per ridurre i costi di trasferimento cross-cloud.
Parità dei dialetti: poiché Spanner Omni supporta gli stessi dialetti GoogleSQL e PostgreSQL e la stessa semantica dello schema di Spanner, le query dell'applicazione vengono eseguite senza modifiche dopo il cutover.

Passaggio 1: crea un flusso di modifiche in tempo reale nel database di origine

Crea un flusso di modifiche in tempo reale nel database Spanner di origine per monitorare le modifiche nelle tabelle di destinazione. Ad esempio, esegui questa istruzione DDL nel tuo database Spanner:

CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
  retention_period = '7d',
  value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);

Sostituisci quanto segue:

CHANGE_STREAM_NAME: il nome del flusso di modifiche, ad esempio CsToOmniDrStream.
TABLE_NAMES: un elenco separato da virgole delle tabelle da monitorare, ad esempio Customers, Orders, AccountBalances o ALL per monitorare tutte le tabelle nel database.

Se imposti retention_period su '7d', i record delle modifiche in tempo reale vengono conservati per un massimo di sette giorni, il che aiuta a prevenire la perdita di dati se la pipeline di replica subisce interruzioni prolungate della manutenzione o della connettività. Per saperne di più, consulta Crea e gestisci i flussi di modifiche in tempo reale.

Passaggio 2: esegui il deployment di una pipeline di Change Data Capture

Per trasmettere le modifiche da Spanner a Spanner Omni, esegui il deployment di una pipeline di Change Data Capture (CDC) continua utilizzando Dataflow con Apache Beam o esegui pod worker personalizzati su Google Kubernetes Engine (GKE) o Amazon EKS.

Una pipeline di replica di produzione esegue queste attività:

Legge le partizioni: utilizza l'API Spanner Change Streams o il connettore Apache Beam SpannerIO per leggere i record delle modifiche in tempo reale tra le partizioni dinamiche delle modifiche in tempo reale. Per saperne di più, consulta Partizioni, record e query delle modifiche in tempo reale ed Elabora i record delle modifiche in tempo reale utilizzando Dataflow.
Memorizza nel buffer e ordina le mutazioni: sequenzia e raggruppa le transazioni in base ai timestamp di commit (commit_timestamp) per intervallo di chiavi o tabella per mantenere la coerenza transazionale e massimizzare il throughput di scrittura.
Scrive su Spanner Omni: si connette tramite gRPC all'endpoint privato del deployment di Spanner Omni e applica le mutazioni raggruppate. Se utilizzi il connettore SpannerIO di Apache Beam con la crittografia, utilizza Apache Beam 2.69.0 o versioni successive per TLS o 2.75.0 o versioni successive per mutual TLS (mTLS). Per saperne di più, consulta Utilizza Apache Beam e SpannerIO per connetterti a Spanner Omni e Autenticazione e autorizzazione.
Monitora il ritardo di replica: monitora la differenza tra l'ora corrente e il commit_timestamp dei record di modifica elaborati in modo da poter generare avvisi sui ritardi di replica.

Se utilizzi Dataflow o Apache Beam, devi utilizzare l'SDK Apache Beam per Java perché l'SDK per Python non include un connettore per le modifiche in tempo reale. Per i pod worker personalizzati, questo esempio Python mostra come configurare un client Spanner Omni utilizzando la crittografia TLS e applicare un batch di mutazioni delle modifiche in tempo reale a un database di destinazione. Per i workload con volumi elevati, metti in coda e raggruppa in batch le mutazioni non sovrapposte in ordine di timestamp di commit tra processi worker paralleli anziché eseguire il commit di un record alla volta:

from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType

# Configure the Spanner Omni target client
omni_client = spanner.Client(
    client_options={"api_endpoint": "ENDPOINT"},
    instance_type=InstanceType.OMNI,
    ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")


def apply_cdc_mutations_to_omni(records):
    """Applies a batch of ordered change stream records to Spanner Omni."""

    def write_batch(transaction):
        for record in records:
            table_name = record["tableName"]
            mutation_type = record["mutationType"]  # INSERT, UPDATE, DELETE
            row_data = record.get("columnValues", {})

            if mutation_type in ("INSERT", "UPDATE"):
                transaction.insert_or_update(
                    table=table_name,
                    columns=list(row_data.keys()),
                    values=[list(row_data.values())],
                )
            elif mutation_type == "DELETE":
                key_columns = record["keyValues"]
                transaction.delete(
                    table=table_name,
                    keyset=spanner.KeySet(keys=[list(key_columns.values())]),
                )

    omni_database.run_in_transaction(write_batch)

Sostituisci quanto segue:

ENDPOINT: l'endpoint gRPC privato e la porta dell'istanza Spanner Omni, ad esempio spanner-omni.internal.example.com:15000.
PATH_TO_CA_CERT: il percorso del file del certificato dell'autorità di certificazione (CA) per il deployment di Spanner Omni.
DATABASE_ID: l'ID del database Spanner Omni di destinazione.

Per saperne di più sulla configurazione delle connessioni client, consulta Utilizza la libreria client Python per connetterti a Spanner Omni.

Accelera la replica con Cross-Cloud Interconnect

L'utilizzo della rete internet pubblica o dei tunnel VPN IPsec tra Google Cloud e un altro cloud provider può introdurre jitter di rete, perdita di pacchetti, limiti di larghezza di banda e ritardo di replica variabile. Per i workload di produzione che richiedono un RPO basso, utilizza Cross-Cloud Interconnect per stabilire una connettività fisica dedicata ad alta velocità traGoogle Cloud e il tuo provider cloud esterno.

La tabella seguente mette a confronto le caratteristiche di rete tra le connessioni internet pubbliche o connessioni VPN IPsec e Cross-Cloud Interconnect.

Confronto delle opzioni di transito di rete per la replica cross-cloud
Metrica di rete	Internet pubblico o VPN IPsec	Cross-Cloud Interconnect
Capacità del link	Da 1,25 Gbps a 3 Gbps per tunnel.	Larghezza di banda ottica dedicata di 10 Gbps o 100 Gbps per link.
Latenza di rete e jitter	Percorsi di transito internet variabili e imprevedibili.	Routing privato deterministico a bassa latenza.
Disponibilità garantita da SLA	Nessuno SLA per le prestazioni end-to-end.	SLA con disponibilità del 99,9% o del 99,99% se configurato con connessioni ridondanti.
Crittografia del trasferimento di dati	Overhead IPsec e limiti di crittografia software.	Crittografia MACsec per Cloud Interconnect (IEEE 802.1AE) con velocità di linea. Per saperne di più, consulta la panoramica di MACsec per Cloud Interconnect.
Costi del trasferimento di dati	Tariffe standard per il traffico in uscita verso internet.	Tariffe ridotte per il trasferimento di dati Cloud Interconnect.

Workflow di configurazione della rete di alto livello

Per configurare Cross-Cloud Interconnect per la pipeline di replica, completa questi passaggi generali:

Ordina connessioni Cross-Cloud Interconnect: ordina porte Cross-Cloud Interconnect primarie e ridondanti in una struttura di colocation che si accoppia con la località del provider cloud remoto. Ad esempio, esegui il comando gcloud compute interconnects create:
```
gcloud compute interconnects create CONNECTION_NAME \
  --interconnect-type=DEDICATED \
  --link-type=CAPACITY \
  --requested-link-count=LINK_COUNT \
  --location=GOOGLE_CLOUD_LOCATION \
  --remote-location=REMOTE_LOCATION \
  --noc-contact-email=CONTACT_EMAIL
```
Sostituisci quanto segue:
- CONNECTION_NAME: il nome della tua connessione Cross-Cloud Interconnect.
- CAPACITY: la capacità del link, ad esempio LINK_TYPE_ETHERNET_10G_LR o LINK_TYPE_ETHERNET_100G_LR.
- LINK_COUNT: il numero di link da richiedere.
- GOOGLE_CLOUD_LOCATION: il dominio di disponibilità edge per la località Google Cloud , ad esempio iad-zone1-1.
- REMOTE_LOCATION: la località del cloud provider remoto, ad esempio aws-us-east-1.
- CONTACT_EMAIL: l'indirizzo email delle operazioni di rete.
Per saperne di più, consulta Scegli le località e Ordina le porte AWS.
Configura il router Cloud e il peering BGP: crea collegamenti VLAN e configura sessioni Border Gateway Protocol (BGP) tra il router Cloud nella tua rete VPC Google Cloud e il gateway privato virtuale o il gateway di connessione diretta nel tuo ambiente cloud remoto. Per saperne di più, consulta Panoramica di router Cloud, Configura le tue risorse Google Cloud e Configura le tue risorse AWS.
Convalida la propagazione delle route: verifica che le tabelle di route in entrambe le reti propaghino blocchi CIDR non sovrapposti in modo che i worker della pipeline CDC e i nodi Spanner Omni comunichino esclusivamente tramite indirizzi IP privati. Per saperne di più, consulta Verifica le connessioni.

Per istruzioni complete sulla configurazione, consulta Connettiti ad Amazon Web Services nella documentazione di Cross-Cloud Interconnect.

Elenco di controllo per failover e runbook

Quando esegui uno switchover o un failover da Spanner su Google Cloud a Spanner Omni, segui questi passaggi operativi:

Svuota le modifiche in corso: interrompi le scritture dell'applicazione nel database Spanner principale (se raggiungibile) e verifica che la pipeline di replica CDC abbia elaborato tutti i record dei flussi di modifiche in tempo reale fino al timestamp di commit più recente.
Reindirizza le connessioni dell'applicazione: aggiorna i profili di configurazione dell'applicazione, le stringhe di connessione o i secret di Kubernetes per connetterti agli endpoint Spanner Omni anziché a Spanner suGoogle Cloud.
Aggiorna il DNS e il routing del traffico: cambia i record DNS o i target del bilanciatore del carico globale per instradare il traffico client al livello dell'applicazione e ai bilanciatori del carico che si trovano davanti al deployment di Spanner Omni.
Risincronizza dopo il ripristino: dopo aver ripristinato l'ambienteGoogle Cloud principale, inverti la direzione della replica prima di eseguire il failback. Puoi acquisire le modifiche in tempo reale da Spanner Omni utilizzando un flusso di modifiche e il connettore Debezium per pubblicare le modifiche in Apache Kafka, con un consumer che le applica a Spanner. In alternativa, puoi esportare il tuo database Spanner Omni in file Avro in Cloud Storage e importarli in Spanner. Per saperne di più, consulta Esporta e importa dati e Importa file Avro di Spanner.

Replica i dati da Spanner a Spanner Omni Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.