Daten von Cloud Spanner nach Cloud Spanner Omni replizieren

In diesem Dokument werden Muster, Konfigurationsschritte und operative Anleitungen zum Einrichten von Notfallwiederherstellungstopologien zwischen verwaltetem Spanner inGoogle Cloud und Spanner Omni in einer externen Umgebung wie AWS oder einem lokalen Rechenzentrum beschrieben.

Durch die Kombination von Transaktionsstreaming mit Änderungsstreams und dedizierter Netzwerkverbindung über Cross-Cloud Interconnect können Sie niedrige Recovery Point Objectives (RPO) und Recovery Time Objectives (RTO) über Cloud-Grenzen hinweg erreichen.

Architektur

In einer cloudübergreifenden Notfallwiederherstellungstopologie dient Spanner inGoogle Cloud als primäre Datenbank und Spanner Omni als Standby-Bereitstellung oder sekundärer Notfallwiederherstellungsstandort. Sie können transaktionale Änderungen mithilfe von Änderungsstreams kontinuierlich replizieren.

In der folgenden Tabelle werden die Datenbankfunktionen, Rollen und Betriebsgrenzen zwischen einer primären Spanner-Bereitstellung und einer sekundären Spanner Omni-Bereitstellung in AWS verglichen.

Vergleich von primären Spanner- und sekundären Spanner Omni-Bereitstellungen

Funktion oder Dimension	Primärer Standort: Spanner auf Google Cloud	Sekundärer Standort: Spanner Omni in AWS
Bereitstellungsmodell	Vollständig verwalteter Dienst auf Google Cloud.	Selbstverwaltete Software in AWS, z. B. Amazon Elastic Compute Cloud (Amazon EC2) oder Amazon Elastic Kubernetes Service (Amazon EKS).
SLA zur Verfügbarkeit	Bis zu 99,999% für multiregionale Konfigurationen und 99,99% für regionale Konfigurationen. Weitere Informationen finden Sie im Spanner-SLA.	Vom Kunden verwaltet; hängt von Ihrer Infrastruktur und Topologie ab.
Replikationsmodus	Synchrone Paxos-basierte Replikation über Zonen und Regionen hinweg.	Asynchrone Change Data Capture (CDC) nahezu in Echtzeit mithilfe von Änderungsstreams.
Recovery Point Objective (RPO)	Nahezu null innerhalb der verwalteten Instanz.	Unter einer Sekunde bis zu mehreren Sekunden über Cloud-Grenzen hinweg, je nach Pipeline-Durchsatz und Netzwerklatenz.
Recovery Time Objective (RTO)	Sofortiges, automatisiertes Failover über Replikate hinweg.	Hängt von Ihrem DNS- und Traffic-Switchover-Runbook ab.
Netzwerk-Transitebene	VPC-Netzwerk-Peering (Virtual Private Cloud) oder Cloud Interconnect.	Cross-Cloud Interconnect-Verbindung zu AWS Direct Connect.
Sicherungsspeicherziel	Von Google verwaltete Spanner-Sicherungen, die nur in verwaltetem Spanner wiederhergestellt werden können.	Cloud Storage oder Amazon Simple Storage Service (Amazon S3), die nur in Spanner Omni wiederhergestellt werden können.

Hinweis

Bevor Sie die Replikation zwischen Spanner und Spanner Omni konfigurieren, muss Ihre Umgebung die folgenden Anforderungen erfüllen:

• Passende Zielkapazität bereitstellen: Dimensionieren Sie Ihre Spanner Omni-Zielbereitstellung so, dass sie der CPU-, Arbeitsspeicher- und Speicher-E/A-Kapazität Ihrer primären Spanner-Instanz entspricht. Eine zu geringe Dimensionierung der Bereitstellung kann zu Replikationsverzögerungen führen und verhindern, dass der Standby-Cluster während eines Failovers Arbeitslasten verarbeitet. Weitere Informationen finden Sie unter Systemanforderungen.
• Datenbankschemas und Referenzdaten synchronisieren: Erstellen Sie die Zieldatenbank und die Tabellen in Spanner Omni mit demselben SQL-Dialekt (GoogleSQL oder PostgreSQL) und denselben Schemadefinitionen wie in Ihrer Spanner-Quelldatenbank. Da Sie eine verwaltete Spanner-Sicherung nicht in Spanner Omni wiederherstellen können, exportieren Sie vorhandene Daten aus Spanner in Avro-Dateien in Cloud Storage und importieren Sie sie in Spanner Omni. Weitere Informationen finden Sie unter Schema und Datenmodell, Mit Spanner Omni entwickeln, Datenbanken von Spanner nach Avro exportieren und Daten importieren und exportieren.
• Private Netzwerkverbindung herstellen: Konfigurieren Sie das private Netzwerkrouting zwischen Ihrem Google Cloud -VPC-Netzwerk und Ihrer externen Umgebung, damit Ihre Replikations-Worker sowohl eine Verbindung zu Spanner als auch zum gRPC-Endpunkt von Spanner Omni herstellen können. Weitere Informationen finden Sie unter Network Connectivity-Produkt auswählen und Replikation mit Cross-Cloud Interconnect beschleunigen.

Daten kontinuierlich mit Änderungsstreams replizieren

Für Anwendungen, die eine cloudübergreifende Geschäftskontinuität erfordern, geben Spanner-Änderungsstreams transaktionale Datenänderungen (INSERT-, UPDATE- und DELETE-Vorgänge) in der Reihenfolge der Commit-Zeitstempel aus. Eine Pipeline für die kontinuierliche Replikation liest Änderungsdatensätze aus Spanner auf Google Cloud und schreibt sie in Ihre Spanner Omni-Bereitstellung.

Die Verwendung von Änderungsstreams für die cloudübergreifende Replikation bietet folgende Vorteile:

• Aktiv-passiver Standby: Behält ein warmes Replikat in Spanner Omni bei, das bereit ist, Arbeitslasten zu verarbeiten, wenn Sie ein Failover initiieren.
• Selektive Replikation: Sie können Änderungsstreams so konfigurieren, dass die gesamte Datenbank überwacht wird, oder sie auf bestimmte Tabellen und Spalten beschränken, um die Kosten für die cloudübergreifende Übertragung zu reduzieren.
• Dialektparität: Da Spanner Omni dieselben GoogleSQL- und PostgreSQL-Dialekte und Schemasemantiken wie Spanner unterstützt, werden Ihre Anwendungsabfragen nach der Umstellung ohne Änderungen ausgeführt.

Schritt 1: Änderungsstream in der Quelldatenbank erstellen

Erstellen Sie einen Änderungsstream in Ihrer Spanner-Quelldatenbank, um Änderungen an Ihren Zieltabellen zu verfolgen. Führen Sie beispielsweise diese DDL-Anweisung in Ihrer Spanner-Datenbank aus:

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

Ersetzen Sie Folgendes:

• CHANGE_STREAM_NAME: der Name Ihres Änderungsstreams, z. B. CsToOmniDrStream.
• TABLE_NAMES: eine durch Kommas getrennte Liste der zu verfolgenden Tabellen, z. B. Customers, Orders, AccountBalances, oder ALL, um alle Tabellen in der Datenbank zu verfolgen.

Wenn Sie retention_period auf '7d' setzen, werden Änderungsstream-Einträge bis zu sieben Tage lang aufbewahrt. So können Sie Datenverluste vermeiden, wenn Ihre Replikationspipeline längere Wartungsarbeiten oder Verbindungsunterbrechungen hat. Weitere Informationen finden Sie unter Änderungsstreams erstellen und verwalten.

Schritt 2: Change Data Capture-Pipeline bereitstellen

Wenn Sie Änderungen von Spanner zu Spanner Omni streamen möchten, stellen Sie eine kontinuierliche Change Data Capture-Pipeline (CDC) mit Dataflow mit Apache Beam bereit oder führen Sie benutzerdefinierte Worker-Pods in Google Kubernetes Engine (GKE) oder Amazon EKS aus.

Eine Produktionsreplikationspipeline führt die folgenden Aufgaben aus:

• Liest Partitionen: Verwendet die Spanner Change Streams API oder den Apache Beam SpannerIO-Connector, um Änderungsdatensätze über dynamische Änderungsstream-Partitionen hinweg zu lesen. Weitere Informationen finden Sie unter Änderungsstream-Partitionen, -Datensätze und -Abfragen und Änderungsstream-Datensätze mit Dataflow verarbeiten.
• Puffert und ordnet Mutationen: Sequenziert und bündelt Transaktionen nach ihren Commit-Zeitstempeln (commit_timestamp) pro Schlüsselbereich oder Tabelle, um die Transaktionskonsistenz aufrechtzuerhalten und den Schreibdurchsatz zu maximieren.
• Schreibt in Spanner Omni: Stellt über gRPC eine Verbindung zum privaten Endpunkt der Spanner Omni-Bereitstellung her und wendet die Batch-Mutationen an. Wenn Sie den Apache Beam SpannerIO-Connector mit Verschlüsselung verwenden, verwenden Sie Apache Beam 2.69.0 oder höher für TLS oder 2.75.0 oder höher für gegenseitiges TLS (mTLS). Weitere Informationen finden Sie unter Apache Beam und SpannerIO für die Verbindung mit Spanner Omni verwenden und Authentifizierung und Autorisierung.
• Überwacht die Replikationsverzögerung: Erfasst die Differenz zwischen der aktuellen Zeit und dem commit_timestamp der verarbeiteten Änderungsdatensätze, damit Sie bei Replikationsverzögerungen benachrichtigt werden können.

Wenn Sie Dataflow oder Apache Beam verwenden, müssen Sie das Apache Beam Java SDK verwenden, da das Python SDK keinen Änderungsstream-Connector enthält. In diesem Python-Beispiel wird gezeigt, wie Sie für benutzerdefinierte Worker-Pods einen Spanner Omni-Client mit TLS-Verschlüsselung konfigurieren und einen Batch von Änderungsstream-Mutationen auf eine Zieldatenbank anwenden. Bei Arbeitslasten mit hohem Volumen sollten Sie sich nicht überschneidende Mutationen in der Reihenfolge der Commit-Zeitstempel über parallele Worker-Prozesse hinweg in die Warteschlange stellen und im Batch verarbeiten, anstatt einen Datensatz nach dem anderen zu committen:

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)

Ersetzen Sie Folgendes:

• ENDPOINT: der private gRPC-Endpunkt und der Port Ihrer Spanner Omni-Instanz, z. B. spanner-omni.internal.example.com:15000.
• PATH_TO_CA_CERT: der Dateipfad zum Zertifikat der Zertifizierungsstelle (CA) für Ihre Spanner Omni-Bereitstellung.
• DATABASE_ID: die ID Ihrer Spanner Omni-Zieldatenbank.

Weitere Informationen zum Konfigurieren von Clientverbindungen finden Sie unter Python-Clientbibliothek für die Verbindung mit Spanner Omni verwenden.

Replikation mit Cross-Cloud Interconnect beschleunigen

Wenn Sie sich auf das öffentliche Internet oder IPsec-VPN-Tunnel zwischen Google Cloudund einem anderen Cloud-Anbieter verlassen, kann dies zu Netzwerk-Jitter, Paketverlust, Bandbreitenbeschränkungen und variabler Replikationsverzögerung führen. Verwenden Sie für Produktionsarbeitslasten, die ein niedriges RPO erfordern, Cross-Cloud Interconnect, um eine dedizierte, physische Hochgeschwindigkeitsverbindung zwischenGoogle Cloud und Ihrem externen Cloud-Anbieter herzustellen.

In der folgenden Tabelle werden die Netzwerkmerkmale von öffentlichen Internet- oder IPsec-VPN-Verbindungen und Cross-Cloud Interconnect verglichen.

Vergleich der Netzwerkübertragungsoptionen für die cloudübergreifende Replikation

Netzwerkmesswert	Öffentliches Internet oder IPsec-VPN	cloudübergreifende Interconnect-Verbindung
Verbindungskapazität	1,25 Gbit/s bis 3 Gbit/s pro Tunnel.	Dedizierte optische Bandbreite von 10 Gbit/s oder 100 Gbit/s pro Link.
Netzwerklatenz und Jitter	Variable und unvorhersehbare Internet-Transitpfade.	Deterministisches privates Routing mit niedriger Latenz.
SLA zur Verfügbarkeit	Kein End-to-End-Leistungs-SLA.	Verfügbarkeits-SLA von 99,9% oder 99,99% bei Konfiguration mit redundanten Verbindungen.
Verschlüsselung bei der Datenübertragung	IPsec-Overhead und Einschränkungen der Softwarekryptografie.	MACsec für Cloud Interconnect (IEEE 802.1AE)-Verschlüsselung mit Leitungsgeschwindigkeit. Weitere Informationen finden Sie unter MACsec für Cloud Interconnect.
Kosten für Datenübertragung	Standardpreise für ausgehenden Internet-Traffic.	Reduzierte Cloud Interconnect-Datenübertragungsraten.

Allgemeiner Workflow für die Netzwerkkonfiguration

Führen Sie die folgenden allgemeinen Schritte aus, um Cross-Cloud Interconnect für Ihre Replikationspipeline einzurichten:

1. Cross-Cloud Interconnect-Verbindungen bestellen: Bestellen Sie primäre und redundante Cross-Cloud Interconnect-Ports in einer Colocation-Einrichtung, die mit dem Standort Ihres Remote-Cloud-Anbieters gekoppelt ist. Führen Sie beispielsweise den Befehl gcloud compute interconnects create aus:

   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
   

   Ersetzen Sie Folgendes:

   • CONNECTION_NAME: der Name Ihrer Cross-Cloud Interconnect-Verbindung.
   • CAPACITY: die Linkkapazität, z. B. LINK_TYPE_ETHERNET_10G_LR oder LINK_TYPE_ETHERNET_100G_LR.
   • LINK_COUNT: die Anzahl der anzufordernden Links.
   • GOOGLE_CLOUD_LOCATION: die Edge-Verfügbarkeitsdomain für den Standort Google Cloud , z. B. iad-zone1-1.
   • REMOTE_LOCATION: der Standort des Remote-Cloud-Anbieters, z. B. aws-us-east-1.
   • CONTACT_EMAIL: die E-Mail-Adresse für den Netzwerkbetrieb.

   Weitere Informationen finden Sie unter Standorte auswählen und AWS-Ports bestellen.

2. Cloud Router und BGP-Peering konfigurieren: Erstellen Sie VLAN-Anhänge und konfigurieren Sie BGP-Sitzungen (Border Gateway Protocol) zwischen dem Cloud Router in Ihrem Google Cloud VPC-Netzwerk und dem Virtual Private Gateway oder Direct Connect Gateway in Ihrer Remote-Cloud-Umgebung. Weitere Informationen finden Sie unter Cloud Router – Übersicht, Google Cloud -Ressourcen konfigurieren und AWS-Ressourcen konfigurieren.

3. Routenweitergabe validieren: Prüfen Sie, ob Routingtabellen in beiden Netzwerken nicht überlappende CIDR-Blöcke weitergeben, damit Ihre CDC-Pipeline-Worker und Spanner Omni-Knoten ausschließlich über private IP-Adressen kommunizieren. Weitere Informationen finden Sie unter Verbindungen prüfen.

Eine vollständige Einrichtungsanleitung finden Sie in der Cross-Cloud Interconnect-Dokumentation unter Verbindung zu Amazon Web Services herstellen.

Checkliste für Failover und Runbook

Wenn Sie einen Switchover oder Failover von Spanner inGoogle Cloud zu Spanner Omni ausführen, gehen Sie so vor:

1. Ausstehende Änderungen ableiten: Beenden Sie die Schreibvorgänge der Anwendung in die primäre Spanner-Datenbank (falls erreichbar) und prüfen Sie, ob Ihre CDC-Replikationspipeline alle Änderungsstream-Einträge bis zum neuesten Commit-Zeitstempel verarbeitet hat.
2. Anwendungsverbindungen weiterleiten: Aktualisieren Sie Ihre Anwendungskonfigurationsprofile, Verbindungsstrings oder Kubernetes-Secrets, um eine Verbindung zu Ihren Spanner Omni-Endpunkten anstelle von Spanner inGoogle Cloudherzustellen.
3. DNS und Traffic-Routing aktualisieren: Ändern Sie Ihre DNS-Einträge oder globalen Load-Balancer-Ziele, um Client-Traffic an die Anwendungsebene und die Load Balancer weiterzuleiten, die Ihrer Spanner Omni-Bereitstellung vorgeschaltet sind.
4. Nach der Wiederherstellung neu synchronisieren: Nachdem Sie die primäreGoogle Cloud -Umgebung wiederhergestellt haben, kehren Sie die Replikationsrichtung um, bevor Sie ein Failback durchführen. Sie erfassen Änderungen aus Spanner Omni mithilfe eines Änderungsstreams und des Debezium-Connectors, um Änderungen in Apache Kafka zu veröffentlichen. Ein Consumer wendet diese dann auf Spanner an. Alternativ können Sie Ihre Spanner Omni-Datenbank in Avro-Dateien in Cloud Storage exportieren und in Spanner importieren. Weitere Informationen finden Sie unter Daten importieren und exportieren und Spanner-Avro-Dateien importieren.

Nächste Schritte

• Spanner Omni-Sicherungen erstellen und verwalten
• Spanner Omni-Sicherung wiederherstellen
• Daten importieren und exportieren
• Apache Beam und SpannerIO verwenden, um eine Verbindung zu Spanner Omni herzustellen
• Debezium für die Verbindung mit Spanner Omni verwenden