Effectuer un remplacement vers MySQL

Ce guide explique comment effectuer une restauration et une reprise après sinistre de Spanner vers vos instances MySQL sources.

Si vous constatez une dégradation inattendue des performances, des erreurs d'application irrécupérables ou des blocages fonctionnels critiques après le basculement vers Spanner, suivez les procédures décrites dans les sections suivantes pour revenir à vos instances MySQL principales :

Avant de commencer

Avant de lancer les procédures de restauration, vérifiez les conditions préalables suivantes :

  1. Réplication inverse active : vérifiez que le pipeline Dataflow de réplication inverse (Spanner_to_SourceDb) est en cours d'exécution et consomme activement les flux de modifications Spanner en mode de filtrage forward_migration. Pour en savoir plus, consultez Configurer la restauration vers MySQL.
  2. Disponibilité de MySQL source : vérifiez que votre base de données MySQL source est en ligne, accessible depuis Dataflow et capable d'accepter les connexions en écriture.
  3. Intervalle de maintenance : informez les parties prenantes qu'un intervalle d'arrêt planifié est requis pendant que les écritures Spanner sont mises en pause et que la réplication inverse est vidée.

Rôles requis

Mettre en pause les écritures Spanner

  1. Mettez en pause tout le trafic d'écriture de la base de données vers Spanner sur votre application.
  2. Autorisez les transactions actives sur Spanner à être entièrement validées et vidées.

Autoriser la réplication inverse à se vider

Les sections suivantes décrivent comment vérifier que toutes les modifications écrites dans Spanner après le basculement sont répliquées dans MySQL avant de changer les écritures de l'application.

Surveiller le délai avant réplication

Suivez le délai avant réplication pour vérifier que toutes les modifications en cours sont écrites dans MySQL :

  1. Dans la Google Cloud console, accédez à la page Job details (Détails du job) de votre job Dataflow de réplication inverse.
  2. Dans l'onglet Custom metrics (Métriques personnalisées), inspectez le compteur utilisateur replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Pour en savoir plus, consultez Configurer la restauration vers MySQL.
  3. Attendez que la valeur du compteur atteigne 0.

Vous pouvez également interroger le compteur utilisateur dans l'explorateur de métriques à l'aide du langage MQL (Monitoring Query Language) : 

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
Remplacez les éléments suivants : * JOB_ID : ID de votre job Dataflow de réplication inverse. * LOGICAL_SHARD_NAME : nom du fragment logique configuré pour votre base de données source.

Vérifier l'activité d'écriture MySQL

Vérifiez que les opérations d'écriture de réplication inverse sont terminées dans votre base de données source :

  1. Dans votre base de données MySQL principale source, inspectez les requêtes actives et les métriques de connexion à la base de données.
  2. Vérifiez que le trafic d'écriture du pipeline de réplication inverse a cessé.

Vérifier l'état propre de la DLQ

Inspectez les files d'attente de lettres mortes (DLQ) pour vérifier qu'aucune erreur non gérée ne s'est produite lors de la réplication inverse :

  1. Dans la Google Cloud console, accédez à la page Job details (Détails du job) de votre job Dataflow de réplication inverse. Dans l'onglet Custom metrics (Métriques personnalisées), inspectez le compteur utilisateur severe_error_count.

  2. Inspectez les répertoires DLQ de réplication inverse graves et de nouvelle tentative dans Cloud Storage (par exemple, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ et gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

    Vous pouvez répertorier le contenu du répertoire DLQ grave à l'aide de la gcloud CLI :

    gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/

    Remplacez les éléments suivants :

    • MIGRATION_BUCKET: nom de votre bucket Cloud Storage.
    • ENV: nom de votre environnement de déploiement (par exemple, prod).
    • SERVICE : nom de votre application ou de votre service.
    • DB_SCHEMA : nom de votre schéma de base de données.

  3. Vérifiez que les répertoires DLQ restent complètement vides.

  4. Si des fichiers d'erreurs existent, résolvez les problèmes sous-jacents et relancez les enregistrements ayant échoué avant de continuer. Pour en savoir plus, consultez Surveiller et résoudre les erreurs de réplication inverse.

Reprendre la diffusion CDC directe

Si vous prévoyez de reprendre la migration directe vers Spanner à l'avenir, reprenez le flux Datastream direct :

  1. Dans la Google Cloud console, accédez à la page Stream details (Détails du flux) de votre flux.
  2. Cliquez sur Resume (Reprendre) et attendez que l'état du flux passe à RUNNING. Pour en savoir plus, consultez Migrer vos données MySQL.

Vous pouvez également reprendre le flux à l'aide de la gcloud CLI en exécutant la commande gcloud datastream streams resume :

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Remplacez les éléments suivants :

  • STREAM_ID: ID de votre flux Datastream.
  • LOCATION : Google Cloud région où se trouve votre flux.

Rediriger les écritures vers MySQL

  1. Mettez à jour la configuration de l'application et les chaînes de connexion à la base de données pour cibler vos instances de base de données MySQL principales sources.
  2. Démarrez les services d'application et reprenez le trafic de lecture et d'écriture en direct sur MySQL.
  3. Vérifiez que les opérations de lecture et d'écriture de l'application s'exécutent correctement sur la base de données MySQL.

Étape suivante