Configurer le remplacement pour MySQL

Cette page explique comment configurer le basculement pour MySQL à l'aide de la réplication inversée. Le terme "fallback" fait référence à un plan de secours permettant de revenir à votre base de données MySQL source si vous rencontrez des problèmes avec Spanner.

La réplication inversée est utile lorsque vous rencontrez des problèmes inattendus et que vous devez revenir à la base de données MySQL d'origine avec un minimum d'interruption du service. La réplication inversée vous permet de revenir en arrière en répliquant les données écrites dans Spanner vers votre base de données MySQL source. Cela garantit que les deux bases de données sont cohérentes à terme.

Le flux de réplication inverse comprend les étapes suivantes, effectuées par le modèle Dataflow Spanner_to_SourceDb :

  1. Lisez les modifications apportées à Spanner à l'aide des flux de modifications Spanner.

  2. Assurez-vous que le mode de filtrage est défini sur forward_migration.

  3. Transformez les données Spanner pour qu'elles soient compatibles avec le schéma de votre base de données source à l'aide de l'outil de migration Spanner. Pour en savoir plus, consultez Transformation personnalisée.

  4. Vérifiez si la base de données source contient déjà des données plus récentes pour la clé primaire spécifiée.

  5. Écrivez les données dans votre base de données source.

Utiliser le modèle Dataflow Spanner_to_SourceDb

Le modèle Dataflow assure la cohérence au niveau de la clé primaire. Le modèle crée des tables de métadonnées, appelées tables fictives, dans Spanner. Elles contiennent l'horodatage de commit de la dernière transaction d'écriture sur le shard pour cette table spécifique.

L'écriture est cohérente jusqu'au code temporel de validation de la clé primaire.

Vous pouvez configurer la tâche Dataflow qui effectue la réplication inverse pour qu'elle s'exécute dans l'un des modes suivants :

  • Standard : il s'agit du mode par défaut. Le job Dataflow lit les événements des flux de modifications Spanner, les convertit en types de données compatibles avec le schéma de la base de données source et les applique à la base de données source. La tâche réessaie automatiquement en cas d'erreur. Une fois les tentatives épuisées, les erreurs sont déplacées vers le dossier severe du répertoire de la file d'attente de lettres mortes (DLQ) dans le bucket Cloud Storage. Le job déplace également toutes les erreurs permanentes vers le dossier severe.

  • RetryDLQ : dans ce mode, le job Dataflow lit les événements du dossier severe de la DLQ et les relance. Exécutez ce mode après avoir corrigé toutes les erreurs permanentes. Dans ce mode, la lecture s'effectue uniquement à partir de la DLQ, et non à partir des flux de modifications Spanner. Si les enregistrements traités à partir du dossier severe sont déplacés vers le dossier retry, le job les réessaie.

Avant de commencer

  • Assurez-vous que la connectivité réseau est établie entre votre base de données MySQL source et votre projetGoogle Cloud , dans lequel vos jobs Dataflow seront exécutés.

  • Ajoutez les adresses IP des nœuds de calcul Dataflow à la liste d'autorisation de votre instance MySQL de destination.

  • Vérifiez que les identifiants MySQL sont correctement spécifiés dans source shards file.

  • Vérifiez que votre instance MySQL est en ligne et en cours d'exécution.

  • Vérifiez que l'utilisateur MySQL dispose des droits INSERT, UPDATE et DELETE sur la base de données MySQL.

  • Vérifiez que vous disposez des autorisations IAM requises pour exécuter un modèle flexible Dataflow. Pour en savoir plus, consultez Créer et exécuter un modèle flexible.

  • Vérifiez que le port 12345 est ouvert pour la communication entre les VM de nœud de calcul Dataflow.

Rôles requis

  • Pour vous assurer que le compte de service Compute Engine dispose des autorisations nécessaires pour lancer la réplication inversée, demandez à votre administrateur d'accorder les rôles IAM suivants au compte de service Compute Engine sur l'instance :

Exécuter la réplication inverse

Pour exécuter la réplication inversée, procédez comme suit :

  1. Importez le fichier de session dans le bucket Cloud Storage.

  2. Créez une notification Pub/Sub pour le dossier retry du répertoire DLQ. Pour ce faire, créez un sujet Pub/Sub et un abonnement Pub/Sub pour ce sujet.

  3. Créez et préparez le modèle Dataflow. Pour en savoir plus, consultez Créer un modèle.

  4. Exécutez le modèle Dataflow de réplication inversée à l'aide de la commande Google Cloud CLI suivante :

      gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  --parameters "startTimestamp=START_TIMESTAMP" \
  --parameters "endTimestamp=END_TIMESTAMP" \
  --parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX" \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]

    Les variables obligatoires sont décrites dans la liste suivante :

    • project : ID du projet Google Cloud .
    • region : la région Google Cloud .
    • template-file-gcs-location : chemin d'accès au fichier Cloud Storage dans lequel vous avez préparé le modèle Dataflow.
    • changeStreamName : nom du flux de modifications Spanner à partir duquel le job lit les données.
    • instanceId : ID de l'instance Spanner.
    • databaseId : ID de la base de données Spanner.
    • spannerProjectId : ID du projet dans lequel résident vos instances Spanner.
    • metadataInstance : instance qui stocke les métadonnées que le connecteur utilise pour contrôler la consommation des données de l'API Change Streams.
    • metadataDatabase : base de données qui stocke les métadonnées que le connecteur utilise pour contrôler la consommation des données de l'API Change Streams.
    • sourceShardsFilePath : chemin d'accès au fichier Cloud Storage contenant les informations du profil de connexion pour les partitions sources.

    Les variables facultatives sont décrites dans la liste suivante :

    • startTimestamp : code temporel à partir duquel commencer à lire les modifications. La valeur par défaut est vide.
    • endTimestamp : code temporel jusqu'auquel lire les modifications. Si vous ne fournissez pas d'horodatage, le processus lit les modifications indéfiniment. La valeur par défaut est vide.
    • shadowTablePrefix : préfixe utilisé pour nommer les tables fantômes. La valeur par défaut est shadow_.
    • sessionFilePath : chemin d'accès au fichier de session dans Cloud Storage contenant les informations de mappage de l'outil de migration Spanner.
    • filtrationMode : mode qui détermine comment filtrer les enregistrements en fonction de critères. Les modes acceptés sont none ou forward_migration.
    • shardingCustomJarPath : emplacement (chemin d'accès) dans Cloud Storage du fichier JAR personnalisé contenant la logique permettant de récupérer l'ID du shard. La valeur par défaut est vide.
    • shardingCustomClassName : nom complet de la classe qui contient l'implémentation de l'ID de partition personnalisé. Ce champ est obligatoire si shardingCustomJarPath est spécifié. La valeur par défaut est vide.
    • shardingCustomParameters : chaîne contenant les paramètres personnalisés à transmettre à la classe de partitionnement personnalisée. La valeur par défaut est vide.
    • sourceDbTimezoneOffset : décalage du fuseau horaire par rapport à UTC pour la base de données source. Exemple : +10:00. Par défaut : +00:00.
    • dlqGcsPubSubSubscription : abonnement Pub/Sub utilisé dans une règle de notification Cloud Storage pour le répertoire de nouvelle tentative de la file d'attente de lettres mortes en mode regular. Spécifiez le nom au format projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. Lorsque vous définissez ce paramètre, le système ignore deadLetterQueueDirectory et dlqRetryMinutes.
    • skipDirectoryName : répertoire dans lequel le système écrit les enregistrements qu'il ignore lors de la réplication inversée. Valeur par défaut : skip.
    • maxShardConnections : nombre maximal de connexions autorisées par partition. Valeur par défaut : 10 000.
    • deadLetterQueueDirectory : chemin d'accès pour stocker la sortie de la DLQ. La valeur par défaut est un répertoire situé sous l'emplacement temporaire du job Dataflow.
    • dlqMaxRetryCount : nombre maximal de nouvelles tentatives en cas d'erreurs temporaires via la file d'attente de lettres mortes. Valeur par défaut : 500.
    • runMode : type de mode d'exécution. Les options sont regular ou retryDLQ. Utilisez retryDLQ pour ne réessayer que les enregistrements DLQ graves. Valeur par défaut : regular.
    • dlqRetryMinutes : nombre de minutes entre les tentatives d'exécution de la file d'attente de lettres mortes. Par défaut : 10.
    • sourceType : type de base de données source vers laquelle effectuer la réplication inversée. Par défaut : mysql.
    • transformationJarPath : emplacement (chemin d'accès) dans Cloud Storage du fichier JAR personnalisé contenant la logique de transformation personnalisée pour le traitement des enregistrements lors de la réplication inversée. La valeur par défaut est vide.
    • transformationClassName : nom de classe complet avec la logique de transformation personnalisée. Ce champ est obligatoire si transformationJarPath est spécifié. La valeur par défaut est vide.
    • transformationCustomParameters : chaîne contenant les paramètres personnalisés à transmettre à la classe de transformation personnalisée. La valeur par défaut est vide.
    • filterEventsDirectoryName : répertoire dans lequel le système écrit les enregistrements qu'il ignore lors de la réplication inversée. Valeur par défaut : skip.

Étape suivante