Configurer le remplacement pour MySQL

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

La réplication inverse est utile lorsque vous rencontrez des problèmes inattendus et que vous devez revenir à la base de données MySQL d'origine avec une interruption minimale du service. La réplication inverse vous permet de revenir en arrière en répliquant les données écrites dans Spanner dans 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 Spanner_to_SourceDb modèle Dataflow :

  1. Lire les modifications à partir de Spanner à l'aide de s flux de modifications Spanner.

  2. Assurez-vous que le mode de filtrage est 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 la section 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 fantômes, dans Spanner qui contiennent l'horodatage de commit de la dernière transaction d'écriture sur le fragment pour cette table particulière.

L'écriture est cohérente jusqu'à l'horodatage de commit 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 :

  • Normal : il s'agit du mode par défaut. La tâche Dataflow lit les événements à partir 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. Après avoir épuisé les tentatives, elle déplace les erreurs vers le dossier severe du répertoire de la file d'attente de lettres mortes (DLQ) dans le bucket Cloud Storage. La tâche déplace également toutes les erreurs permanentes vers le dossier severe.

  • RetryDLQ : dans ce mode, la tâche Dataflow lit les événements à partir du dossier severe de la DLQ et les réessaie. Exécutez ce mode après avoir corrigé toutes les erreurs permanentes. Ce mode ne lit que depuis la DLQ, et non depuis les flux de modifications Spanner. Si les enregistrements traités à partir du dossier severe sont déplacés vers le dossier retry, la tâche 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 Google Cloud projet, où vos tâches Dataflow s'exécuteront.

  • Autorisez les adresses IP des nœuds de calcul Dataflow dans votre instance MySQL de destination.

  • Vérifiez que les identifiants MySQL sont correctement spécifiés dans le 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 privilèges 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 Flex Dataflow. Pour en savoir plus, consultez la section Créer et exécuter un modèle Flex.

  • 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 inverse, 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 inverse, 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 Pub/Sub sujet et un Pub/Sub abonnement pour ce sujet.

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

  4. Exécutez le modèle Dataflow de réplication inverse à 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 Google Cloud projet.
    • region : the Google Cloud région.
    • 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 la tâche lit.
    • 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 de flux de modifications.
    • 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 de flux de modifications.
    • sourceShardsFilePath: chemin d'accès au fichier Cloud Storage contenant les informations de profil de connexion pour les fragments sources.

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

    • startTimestamp : horodatage à partir duquel commencer à lire les modifications. La valeur par défaut est vide.
    • endTimestamp : horodatage 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 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 compatibles sont none ou forward_migration.
    • shardingCustomJarPath: emplacement (chemin d'accès) dans Cloud Storage du fichier JAR personnalisé contenant la logique permettant d'extraire l'ID de fragment. La valeur par défaut est vide.
    • shardingCustomClassName: nom de classe complet avec l'implémentation personnalisée de l'ID de fragment. 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 fragmentation personnalisée. La valeur par défaut est vide.
    • sourceDbTimezoneOffset: décalage de fuseau horaire par rapport à UTC pour la base de données source. Exemple : +10:00. Valeur 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 DLQ 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 inverse. Valeur par défaut : skip.
    • maxShardConnections : nombre maximal de connexions autorisées par fragment. 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 raison d'erreurs temporaires via la DLQ. Valeur par défaut : 500.
    • runMode : type de mode d'exécution. Les options sont regular ou retryDLQ. Utilisez retryDLQ pour réessayer uniquement les enregistrements DLQ graves. Valeur par défaut : regular.
    • dlqRetryMinutes : nombre de minutes entre les nouvelles tentatives de la DLQ. Valeur par défaut : 10.
    • sourceType : type de base de données source vers laquelle effectuer la réplication inverse. Valeur 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 inverse. La valeur par défaut est vide.
    • transformationClassName: nom de classe complet avec une 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 inverse. Valeur par défaut : skip.

Étape suivante