Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Répliquer des données de Spanner vers Spanner Omni

Ce document décrit les modèles, les étapes de configuration et les conseils opérationnels pour configurer des topologies de reprise après sinistre entre Spanner géré surGoogle Cloud et Spanner Omni dans un environnement externe tel qu'AWS ou un centre de données sur site.

En combinant le streaming de transactions à l'aide de flux de modifications et la connectivité réseau dédiée via interconnexion cross-cloud, vous pouvez atteindre des objectifs de point de récupération (RPO) et de temps de récupération (RTO) faibles au-delà des limites du cloud.

Présentation de l'architecture

Dans une topologie de reprise après sinistre cross-cloud, Spanner surGoogle Cloud sert de base de données principale, et Spanner Omni sert de déploiement de secours ou de site de reprise après sinistre secondaire. Vous pouvez répliquer les modifications transactionnelles en continu à l'aide de flux de modifications.

Le tableau suivant compare les fonctionnalités, les rôles et les limites opérationnelles de la base de données entre un déploiement Spanner principal et un déploiement Spanner Omni secondaire sur AWS.

Comparaison des déploiements Spanner principal et Spanner Omni secondaire
Capacité ou dimension	Site principal : Spanner sur Google Cloud	Site secondaire : Spanner Omni sur AWS
Modèle de déploiement	Service entièrement géré sur Google Cloud.	Logiciels autogérés sur AWS, tels qu'Amazon Elastic Compute Cloud (Amazon EC2) ou Amazon Elastic Kubernetes Service (Amazon EKS).
SLA de disponibilité	Jusqu'à 99,999% pour les configurations multirégionales et 99,99% pour les configurations régionales. Pour en savoir plus, consultez le SLA Spanner.	Géré par le client ; dépend de votre infrastructure et de votre topologie.
Mode de réplication	Réplication synchrone basée sur Paxos entre les zones et les régions.	Capture des données modifiées (CDC) asynchrone en temps quasi réel à l'aide de flux de modifications.
Objectif de point de reprise après sinistre (RPO) :	Quasiment nul dans l'instance gérée.	De moins d'une seconde à quelques secondes au-delà des limites du cloud, en fonction du débit du pipeline et de la latence du réseau.
Objectif de temps de récupération (RTO) :	Basculement immédiat et automatisé entre les instances répliquées.	Cela dépend de votre runbook de basculement du DNS et du trafic.
Couche de transit réseau	Appairage de réseaux de cloud privé virtuel (VPC) ou Cloud Interconnect.	Interconnexion cross-cloud connecté à AWS Direct Connect.
Cible de stockage de sauvegarde	Sauvegardes Spanner gérées par Google, qui ne peuvent être restaurées que dans Spanner géré.	Cloud Storage ou Amazon Simple Storage Service (Amazon S3), qui ne peuvent être restaurées que dans Spanner Omni.

Avant de commencer

Avant de configurer la réplication entre Spanner et Spanner Omni, assurez-vous que votre environnement répond aux exigences suivantes :

Provisionner une capacité de destination correspondante : dimensionnez votre déploiement Spanner Omni de destination pour qu'il corresponde à la capacité d'E/S du processeur, de la mémoire et du stockage de votre instance Spanner principale. Un sous-dimensionnement du déploiement peut entraîner un délai de réplication et empêcher le cluster de secours de gérer les charges de travail lors d'un basculement. Pour en savoir plus, consultez Configuration système requise.
Synchroniser les schémas de base de données et les données de référence : créez la base de données et les tables de destination dans Spanner Omni en utilisant le même dialecte SQL (GoogleSQL ou PostgreSQL) et les mêmes définitions de schéma que votre base de données Spanner source. Comme vous ne pouvez pas restaurer une sauvegarde Spanner gérée dans Spanner Omni, exportez les données existantes de Spanner vers des fichiers Avro dans Cloud Storage, puis importez-les dans Spanner Omni. Pour en savoir plus, consultez Schéma et modèle de données, Développer avec Spanner Omni, Exporter des bases de données de Spanner vers Avro et Importer et exporter des données.
Établir une connectivité réseau privée : configurez le routage réseau privé entre votre réseau VPC Google Cloud et votre environnement externe afin que vos nœuds de calcul de réplication puissent se connecter à la fois à Spanner et au point de terminaison gRPC Spanner Omni. Pour en savoir plus, consultez Choisir un produit de connectivité réseau et Accélérer la réplication avec Cross-Cloud Interconnect.

Répliquer des données en continu à l'aide de flux de modifications

Pour les applications qui nécessitent une continuité d'activité cross-cloud, les flux de modifications Spanner génèrent des modifications de données transactionnelles (opérations INSERT, UPDATE et DELETE) dans l'ordre des codes temporels de commit. Un pipeline de réplication continue lit les enregistrements de modifications de Spanner sur Google Cloud et les écrit dans votre déploiement Spanner Omni.

L'utilisation de flux de modifications pour la réplication cross-cloud offre les avantages suivants :

Mode de secours actif-passif : maintient une instance répliquée de secours sur Spanner Omni, prête à diffuser les charges de travail lorsque vous lancez un basculement.
Réplication sélective : vous pouvez configurer les flux de modifications pour qu'ils surveillent l'intégralité de la base de données ou les limiter à des tables et des colonnes spécifiques afin de réduire les coûts de transfert cross-cloud.
Parité des dialectes : comme Spanner Omni est compatible avec les mêmes dialectes GoogleSQL et PostgreSQL et la même sémantique de schéma que Spanner, les requêtes de votre application s'exécutent sans modification après le basculement.

Étape 1 : Créez un flux de modifications sur la base de données source

Créez un flux de modifications sur votre base de données Spanner source pour suivre les modifications apportées à vos tables cibles. Par exemple, exécutez cette instruction LDD dans votre base de données Spanner :

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

Remplacez les éléments suivants :

CHANGE_STREAM_NAME : nom de votre flux de modifications, par exemple CsToOmniDrStream.
TABLE_NAMES : liste de tables à suivre, séparées par une virgule, par exemple Customers, Orders, AccountBalances, ou ALL pour suivre toutes les tables de la base de données.

La définition de retention_period sur '7d' conserve les enregistrements du flux de modifications pendant sept jours maximum, ce qui permet d'éviter la perte de données si votre pipeline de réplication subit des interruptions de maintenance ou de connectivité prolongées. Pour en savoir plus, consultez Créer et gérer des flux de modifications.

Étape 2 : Déployer un pipeline de capture des données modifiées

Pour diffuser les modifications de Spanner vers Spanner Omni, déployez un pipeline de capture de données modifiées (CDC) en continu à l'aide de Dataflow avec Apache Beam, ou exécutez des pods de nœuds de calcul personnalisés sur Google Kubernetes Engine (GKE) ou Amazon EKS.

Un pipeline de réplication de production effectue les tâches suivantes :

Lit les partitions : utilise l'API Spanner Change Streams ou le connecteur Apache Beam SpannerIO pour lire les enregistrements de modifications sur les partitions de flux de modifications dynamiques. Pour en savoir plus, consultez Partitions, enregistrements et requêtes de flux de modifications et Traiter les enregistrements de flux de modifications à l'aide de Dataflow.
Mise en mémoire tampon et classement des mutations : séquence et traite par lot les transactions en fonction de leur code temporel de commit (commit_timestamp) par plage de clés ou par table afin de maintenir la cohérence transactionnelle et de maximiser le débit d'écriture.
Écritures dans Spanner Omni : se connecte via gRPC au point de terminaison privé du déploiement Spanner Omni et applique les mutations par lot. Si vous utilisez le connecteur Apache Beam SpannerIO avec chiffrement, utilisez Apache Beam 2.69.0 ou une version ultérieure pour TLS, ou 2.75.0 ou une version ultérieure pour TLS mutuel (mTLS). Pour en savoir plus, consultez Utiliser Apache Beam et SpannerIO pour vous connecter à Spanner Omni et Authentification et autorisation.
Surveille le délai de réplication : suit la différence entre l'heure actuelle et le commit_timestamp des enregistrements de modification traités afin de pouvoir vous alerter en cas de retard de réplication.

Si vous utilisez Dataflow ou Apache Beam, vous devez utiliser le SDK Java Apache Beam, car le SDK Python n'inclut pas de connecteur de flux de modifications. Pour les pods de nœuds de calcul personnalisés, cet exemple Python montre comment configurer un client Spanner Omni à l'aide du chiffrement TLS et appliquer un lot de mutations de flux de modifications à une base de données de destination. Pour les charges de travail volumineuses, mettez en file d'attente et traitez par lot les mutations qui ne se chevauchent pas, dans l'ordre des codes temporels de commit, sur des processus de nœuds de calcul parallèles, plutôt que de valider un enregistrement à la fois :

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)

Remplacez les éléments suivants :

ENDPOINT : point de terminaison gRPC privé et port de votre instance Spanner Omni, par exemple spanner-omni.internal.example.com:15000.
PATH_TO_CA_CERT : chemin d'accès au certificat de l'autorité de certification (CA) pour votre déploiement Spanner Omni.
DATABASE_ID : ID de votre base de données Spanner Omni de destination.

Pour en savoir plus sur la configuration des connexions clientes, consultez Utiliser la bibliothèque cliente Python pour vous connecter à Spanner Omni.

Accélérer la réplication avec interconnexion cross-cloud

S'appuyer sur l'Internet public ou sur des tunnels VPN IPsec entre Google Cloudet un autre fournisseur de services cloud peut entraîner une instabilité du réseau, une perte de paquets, des limites de bande passante et un délai de réplication variable. Pour les charges de travail de production nécessitant un RPO faible, utilisez Cross-Cloud Interconnect afin d'établir une connectivité physique dédiée à haut débit entreGoogle Cloud et votre fournisseur de services cloud externe.

Le tableau suivant compare les caractéristiques réseau entre les connexions Internet publiques ou VPN IPsec et interconnexion cross-cloud.

Comparaison des options de transit réseau pour la réplication cross-cloud
Métrique réseau	Internet public ou VPN IPsec	Cross-Cloud Interconnect
Capacité de liaison	1,25 Gbit/s à 3 Gbit/s par tunnel.	Bande passante optique dédiée de 10 Gbit/s ou 100 Gbit/s par liaison.
Latence et gigue du réseau	Chemins de transit Internet variables et imprévisibles.	Routage privé déterministe à faible latence.
SLA de disponibilité	Pas de contrat de niveau de service de bout en bout pour les performances.	SLA de disponibilité de 99,9% ou 99,99% lorsqu'il est configuré avec des connexions redondantes.
Chiffrement du transfert de données	Surcharge IPsec et limites de la cryptographie logicielle.	Chiffrement MACsec pour Cloud Interconnect (IEEE 802.1AE) au débit de la ligne. Pour en savoir plus, consultez la page Présentation de MACsec pour Cloud Interconnect.
Coûts de transfert de données	Tarifs de sortie Internet standards.	Tarifs réduits pour le transfert de données Cloud Interconnect.

Workflow de configuration réseau de haut niveau

Pour configurer interconnexion cross-cloud pour votre pipeline de réplication, procédez comme suit :

Commander de interconnexion cross-cloud Interconnect : commandez des ports interconnexion cross-cloud principaux et redondants dans une installation hébergée en colocation qui s'associe à l'emplacement de votre fournisseur de services cloud distant. Par exemple, exécutez la commande 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
```
Remplacez les éléments suivants :
- CONNECTION_NAME : nom de votre connexion interconnexion cross-cloud.
- CAPACITY : capacité de la liaison, par exemple LINK_TYPE_ETHERNET_10G_LR ou LINK_TYPE_ETHERNET_100G_LR.
- LINK_COUNT : nombre de liens à demander.
- GOOGLE_CLOUD_LOCATION : domaine de disponibilité de périphérie pour l'emplacement Google Cloud , par exemple iad-zone1-1.
- REMOTE_LOCATION : emplacement du fournisseur de services cloud distant, par exemple aws-us-east-1.
- CONTACT_EMAIL : l'adresse e-mail de vos opérations réseau.
Pour en savoir plus, consultez Choisir vos emplacements et Commander vos ports AWS.
Configurer Cloud Router et l'appairage BGP : créez des rattachements de VLAN et configurez des sessions BGP (Border Gateway Protocol) entre Cloud Router dans votre réseau VPC Google Cloud et la passerelle privée virtuelle ou la passerelle de connexion directe dans votre environnement cloud distant. Pour en savoir plus, consultez Présentation de Cloud Router, Configurer vos ressources Google Cloud et Configurer vos ressources AWS.
Valider la propagation des routes : vérifiez que les tables de routage des deux réseaux propagent des blocs CIDR qui ne se chevauchent pas, afin que les nœuds de calcul de votre pipeline CDC et les nœuds Spanner Omni communiquent exclusivement via des adresses IP privées. Pour en savoir plus, consultez Vérifier vos connexions.

Pour obtenir des instructions de configuration complètes, consultez Se connecter à Amazon Web Services dans la documentation interconnexion cross-cloud.

Checklist pour le basculement et le runbook

Lorsque vous effectuez une permutation ou un basculement de Spanner surGoogle Cloud vers Spanner Omni, procédez comme suit :

Drainer les modifications en cours : arrêtez les écritures de l'application dans la base de données Spanner principale (si elle est accessible) et vérifiez que votre pipeline de réplication CDC a traité tous les enregistrements de flux de modifications jusqu'au dernier code temporel de commit.
Rediriger les connexions d'application : mettez à jour les profils de configuration de votre application, les chaînes de connexion ou les secrets Kubernetes pour vous connecter à vos points de terminaison Spanner Omni au lieu de Spanner surGoogle Cloud.
Mettre à jour le DNS et le routage du trafic : changez vos enregistrements DNS ou vos cibles d'équilibreur de charge mondial pour acheminer le trafic client vers le niveau d'application et les équilibreurs de charge devant votre déploiement Spanner Omni.
Resynchroniser après la récupération : après avoir restauré l'environnement principalGoogle Cloud , inversez le sens de la réplication avant de basculer. Vous capturez les modifications de Spanner Omni à l'aide d'un flux de modifications et du connecteur Debezium pour publier les modifications dans Apache Kafka, avec un consommateur qui les applique à Spanner. Vous pouvez également exporter votre base de données Spanner Omni vers des fichiers Avro dans Cloud Storage, puis les importer dans Spanner. Pour en savoir plus, consultez Importer et exporter des données et Importer des fichiers Avro Spanner.

Répliquer des données de Spanner vers Spanner Omni Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.