Effectuer la bascule depuis MySQL

Ce guide explique comment effectuer la bascule d'une migration de base de données en direct d'une instance source MySQL vers une base de données Spanner à l'aide de Datastream et de Dataflow.

Avant de commencer

Avant d'effectuer la bascule, vérifiez que vous avez effectué les tâches suivantes dans le cadre de votre migration de données en direct :

  1. Migration du schéma : déployez votre schéma dans Spanner. Pour en savoir plus, consultez Migrer un schéma depuis MySQL.
  2. Migration de remplissage : effectuez la migration initiale des données à l'aide du job Dataflow de migration de remplissage. Pour en savoir plus, consultez Effectuer la migration de remplissage.
  3. Réplication CDC active : vérifiez que la réplication continue de la capture des données modifiées (CDC) est active et saine :
    • Le flux Datastream lit activement les événements de modification de votre base de données source MySQL et les écrit dans le bucket Cloud Storage.
    • Les notifications du bucket Cloud Storage publient des événements de création d'objet dans le sujet Pub/Sub.
    • Le job Dataflow de flux continu (Cloud_Datastream_to_Spanner) consomme l'abonnement Pub/Sub et écrit les modifications dans Spanner avec un décalage de réplication inférieur à la seconde ou négligeable. Pour en savoir plus, consultez Migrer vos données MySQL.
  4. Validation initiale des données : exécutez des vérifications de validation des données pour vérifier la cohérence des données entre l'instance source MySQL et la cible Spanner. Pour en savoir plus, consultez Valider la migration de vos données.
  5. Nettoyer l'état de la file d'attente de lettres mortes (DLQ) : vérifiez que le répertoire DLQ grave de réplication directe dans Cloud Storage (par exemple, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) est complètement vide. Si des erreurs graves existent, résolvez les problèmes sous-jacents et relisez tous les événements de modification ayant échoué à l'aide d'un job par lot retryDLQ avant de commencer la bascule. Pour en savoir plus, consultez Surveiller et résoudre les erreurs de DLQ CDC.
  6. Configuration de la réplication inverse (préparation au basculement) : si vous avez besoin d' un chemin de basculement de secours, configurez un pipeline de réplication inverse actif de Spanner vers votre base de données source MySQL. Pour en savoir plus, consultez Configurer le basculement vers MySQL.

Rôles requis

Effectuer la bascule

Les sections suivantes expliquent comment drainer le pipeline d'écriture et vérifier que toutes les modifications sources sont répliquées dans Spanner avant de basculer les écritures de l'application.

Vérifier l'état du pipeline et de la DLQ

Avant de mettre en pause le trafic d'écriture de l'application ou de lancer un temps d'arrêt, vérifiez que votre pipeline de réplication directe ne comporte aucun événement de modification bloqué dans sa DLQ :

  1. Dans la Google Cloud console, accédez à la page Détails du job de votre pipeline Dataflow de flux continu.
  2. Dans l'onglet Métriques personnalisées, inspectez le compteur personnalisé Total permanent errors.

  3. Si ce compteur est supérieur à 0, vérifiez votre répertoire DLQ grave Cloud Storage (par exemple, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) et assurez-vous qu'il est vide.

Mettre en pause les écritures de l'application

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

Suivre et mettre en pause Datastream

  1. Dans la Google Cloud console, accédez à la page Détails du flux de votre flux.
  2. Dans l'onglet Surveillance, inspectez le graphique Fraîcheur des données (type de métrique Cloud Monitoring : datastream.googleapis.com/stream/freshness). Attendez que la valeur de la métrique diminue à 0. Cela indique que Datastream a capturé et traité toutes les modifications de la base de données source jusqu'au moment où les écritures ont été mises en pause. Pour en savoir plus, consultez Surveiller un flux.

  3. Vérifiez qu'aucun événement de réplication ne passe par le flux. Dans l'onglet Surveillance, inspectez le graphique Débit (type de métrique Monitoring : datastream.googleapis.com/stream/event_count) et vérifiez que le taux d'événements est 0.

    Vous pouvez également vérifier par programmation à l'aide de l'explorateur de métriques en interrogeant le nombre d'événements à l'aide du langage MQL (Monitoring Query Language) : 

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     Remplacez STREAM_ID par l'ID de votre flux.

    Vérifiez que cette métrique indique 0 pendant au moins deux périodes d'agrégation consécutives.

  4. Mettez en pause votre flux Datastream à l'aide de la Google Cloud console ou de l'API, et attendez que l'état du flux passe à PAUSED.

Attendre que les données de modification en cours soient drainées

  1. Dans la Google Cloud console, accédez à la page Détails du flux de votre flux.
  2. Dans l'onglet Surveillance, inspectez le graphique Latence du système (type de métrique Monitoring : datastream.googleapis.com/stream/system_latencies).
  3. Notez la valeur de latence du 99e centile (P99) et attendez au moins deux fois la latence du système P99 plus 30 secondes après avoir mis en pause votre flux. Cette période d'attente permet de s'assurer que tous les fichiers de données de modification générés avant la mise en pause sont écrits en toute sécurité dans Cloud Storage et que leurs événements de création d'objet sont publiés dans Pub/Sub.
  4. Vérifiez que votre job Dataflow de flux continu a consommé tous les événements de modification en attente. Dans la Google Cloud console, accédez à la page Abonnements Pub/Sub, puis sélectionnez l' abonnement créé lors de la configuration de votre migration CDC.
  5. Dans l'onglet Surveillance, inspectez le graphique Nombre de messages non reconnus (type de métrique Monitoring : pubsub.googleapis.com/subscription/num_undelivered_messages) et vérifiez que le nombre est 0.

Vérifier que la réplication est terminée

  1. Vérifiez que votre pipeline Dataflow de flux continu a terminé d'écrire toutes les modifications répliquées. Sur la page Détails du job de votre job de flux continu, sélectionnez l'onglet Métriques personnalisées, puis inspectez le compteur utilisateur Replication lag total latency_MAX. Attendez que la valeur du compteur atteigne 0.

    Vous pouvez également interroger le compteur utilisateur dans l'explorateur de métriques à l'aide de MQL : 

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     Remplacez JOB_ID par l'ID de votre job Dataflow.

  2. Vérifiez que l'activité d'écriture s'est arrêtée sur la base de données Spanner cible. Sur la page Détails de la base de données de votre base de données cible, sélectionnez l'onglet Surveillance et inspectez le graphique Débit d'écriture (type de métrique Monitoring : spanner.googleapis.com/transaction_stat/total/bytes_written_count). Vérifiez que le débit d'écriture est 0 pendant au moins deux périodes d'agrégation consécutives d'une minute.

  3. Effectuez une dernière vérification de votre DLQ de réplication directe. Inspectez les répertoires DLQ graves et de nouvelle tentative dans Cloud Storage (par exemple, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ et gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) pour vérifier qu'ils restent vides.

  4. Drainez votre job Dataflow de flux continu :

    1. Dans la Google Cloud console, accédez à la page Détails du job de votre job de flux continu.
    2. Cliquez sur Arrêter le job, sélectionnez Drainer, puis cliquez sur Arrêter le job.
    3. Attendez que l'état du job passe à Drained. Pour en savoir plus, consultez Arrêter un pipeline en cours d'exécution.

  5. Effectuez une vérification de la DLQ après le drainage : une fois l'état du job passé à Drained, inspectez une dernière fois les répertoires DLQ graves et de nouvelle tentative dans Cloud Storage. Vérifiez qu'aucun nouveau fichier d'erreur n'est apparu pendant le drainage des données en cours. Si des fichiers existent, résolvez-les et relisez-les. Pour en savoir plus, consultez Surveiller et résoudre les erreurs de DLQ CDC.

Effectuer la bascule de l'application

Basculez les connexions de la base de données de l'application vers Spanner et reprenez le trafic de lecture et d'écriture en direct :

  1. Mettez à jour la configuration de l'application ou les chaînes de connexion à la base de données pour cibler votre base de données Spanner.
  2. Démarrez les services d'application et vérifiez que le trafic de lecture et d'écriture en direct s'exécute correctement sur Spanner.
  3. Surveillez votre pipeline de réplication inverse pour détecter les erreurs. Si une écriture Spanner ne parvient pas à être répliquée dans MySQL, Dataflow enregistre l'enregistrement ayant échoué dans un répertoire DLQ de Cloud Storage (par exemple, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Vérifiez régulièrement ce chemin d'accès pour vous assurer qu'il reste vide. Si des enregistrements ayant échoué apparaissent, consultez Surveiller et résoudre les erreurs de réplication inverse.

Étape suivante