Gérer des instances dupliquées avec accès en lecture

Cette page vous explique comment gérer les instances dupliquées avec accès en lecture. Ces opérations incluent la désactivation et l'activation de la réplication, la promotion d'une instance dupliquée, la configuration de la réplication parallèle et la vérification de l'état de réplication.

Pour en savoir plus sur le fonctionnement de la réplication, consultez la page Réplication dans Cloud SQL.

Désactiver la duplication

La réplication est activée par défaut au démarrage d'une instance dupliquée. Toutefois, vous avez la possibilité de désactiver la réplication, par exemple à des fins de débogage ou d'analyse de l'état d'une instance. Lorsque vous êtes prêt, vous pouvez la réactiver de façon explicite. La désactivation ou la réactivation de la réplication ne redémarre pas l'instance dupliquée.

La désactivation de la réplication n'arrête pas l'instance dupliquée. Celle-ci devient une instance avec accès en lecture seule qui ne réplique plus son instance maître. Les frais liés à l'instance continuent de vous être facturés. Sur l'instance dupliquée, vous pouvez réactiver la réplication, la supprimer, ou la promouvoir en instance autonome.

Pour désactiver la réplication, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Désactiver la duplication dans la barre de boutons.
  4. Cliquez sur OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--no-enable-database-replication

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "False"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Activer la duplication

Lorsqu'une instance dupliquée ne réplique aucune donnée pendant une longue période, il lui faut plus de temps pour rattraper l'instance maître. Dans ce cas, supprimez l'instance dupliquée et créez-en une autre.

Pour activer la réplication, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Activer la duplication.
  4. Cliquez sur OK.

gcloud

gcloud sql instances patch REPLICA_NAME \
--enable-database-replication

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.patch" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name

Corps JSON de la requête :

{
  "settings":
  {
    "databaseReplicationEnabled": "True"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Promouvoir une instance dupliquée

La promotion d'une instance dupliquée avec accès en lecture entraîne l'arrêt de la réplication et la transformation de l'instance en instance principale Cloud SQL autonome avec accès en lecture et écriture.

Lorsque elles sont promues, les instances dupliquées avec accès en lecture sont automatiquement configurées avec des sauvegardes, mais elles ne sont pas configurées en tant qu'instances à haute disponibilité. Vous pouvez activer la haute disponibilité après leur promotion, comme vous le feriez avec n'importe quelle instance non répliquée. La configuration d'une instance dupliquée avec accès en lecture pour la haute disponibilité s'effectue de la même manière que pour une instance principale. Découvrez comment configurer l'instance pour la haute disponibilité.

Si l'instance principale est toujours disponible et traite les requêtes des clients, vous devez effectuer les opérations suivantes avant de promouvoir une instance dupliquée avec accès en lecture :

  1. Arrêtez toutes les opérations en écriture sur l'instance principale.
  2. Vérifiez l'état de réplication de l'instance dupliquée (suivez les instructions de l'onglet Client MySQL).
  3. Vous devez vérifier que l'instance dupliquée est en cours de duplication, puis attendre que le délai de duplication signalé par la métrique Seconds_Behind_Master atteigne 0.

Sinon, il est possible que certaines des transactions validées sur l'instance principale soient manquantes dans l'instance nouvellement promue.

Pour promouvoir une instance dupliquée en instance autonome, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Sélectionnez une instance dupliquée en cliquant sur son nom.
  3. Cliquez sur Promouvoir une instance dupliquée.
  4. Cliquez sur OK.

gcloud

gcloud sql instances promote-replica REPLICA_NAME

REST v1

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.promoteReplica" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/replica-name/promoteReplica

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

Pour exécuter cette commande cURL dans une invite de ligne de commande, vous devez obtenir un jeton d'accès à l'aide de la commande gcloud auth print-access-token. Vous pouvez également utiliser APIs Explorer sur la page dédiée à la méthode "instances.promoteReplica" pour envoyer la requête d'API REST.

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • project-id : ID du projet
  • replica-name : nom de l'instance dupliquée

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/replica-name/promoteReplica

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

Vérifiez que l'instance promue est configurée correctement. Envisagez en particulier de configurer la haute disponibilité de l'instance si nécessaire.

configurer la réplication parallèle.

La réduction du délai avant réplication est importante pour gérer les performances de réplication. Un délai avant réplication survient lorsque les mises à jour d'une instance dupliquée avec accès en lecture sont en retard par rapport aux mises à jour de l'instance principale. Cette section explique comment les utilisateurs peuvent activer la réplication parallèle, ce qui peut réduire le délai avant réplication.

Dans la réplication MySQL, un thread SQL de réplication permet d'exécuter les transactions collectées dans le journal de relais de l'instance dupliquée avec accès en lecture. La réplication parallèle réduit le délai de réplication en augmentant le nombre de threads SQL qui exécutent ces transactions. Les instances dupliquées avec accès en lecture pour lesquelles la réplication parallèle est activée sont parfois appelées "instances dupliquées multithread".

La réplication parallèle est disponible dans les trois scénarios suivants dans Cloud SQL pour MySQL :

Par souci de simplicité, cette page utilise les termes "instance principale" et "instance dupliquée avec accès en lecture".

Étapes de base pour modifier les options de réplication parallèle

Pour activer la réplication parallèle, procédez comme suit :

  1. Sur l'instance dupliquée avec accès en lecture, désactivez la réplication.
  2. Sur l'instance dupliquée avec accès en lecture, définissez les options pour la réplication parallèle. Exécutez la commande gcloud pour définir les options. L'option de la console Google Cloud est désactivée lorsque la réplication est désactivée.
  3. Toujours sur la même instance, activez la réplication.
  4. Sur l'instance principale, vous pouvez définir les options permettant d'optimiser les performances pour la réplication parallèle si vous le souhaitez.

Instances dupliquées avec accès en lecture : options de réplication parallèle

Cloud SQL pour MySQL accepte plusieurs options de réplication parallèle sur les instances dupliquées avec accès en lecture. Pour en savoir plus sur les options, cliquez sur les liens suivants vers la documentation MySQL 8.0 :

La modification de ces options ne redémarre pas l'instance dupliquée avec accès en lecture.

Le tableau suivant contient les plages autorisées et les valeurs par défaut pour ces options :

Option de l'instance dupliquée avec accès en lecture Valeurs autorisées MySQL 5.7 (valeur par défaut) MySQL 8.0 et versions ultérieures (valeur par défaut)
replica_parallel_workers 0-1024 0 0 (MySQL 8.0.26 et versions antérieures)
4 (MySQL 8.0.27 et versions ultérieures)
replica_parallel_type DATABASE, LOGICAL_CLOCK DATABASE DATABASE (MySQL 8.0.26 et versions antérieures)
LOGICAL_CLOCK (MySQL 8.0.27 et versions ultérieures)
replica_preserve_commit_order ON, OFF OFF OFF (MySQL 8.0.26 et versions antérieures)
ON (MySQL 8.0.27 et versions ultérieures)
replica_pending_jobs_size_max 1024-1 Go 16 Mo 128 Mo

L'option replica_preserve_commit_order évite les trous dans la séquence des transactions exécutées à partir du journal de relais de l'instance dupliquée.

Le paramètre replica_preserve_commit_order=1 requiert les opérations suivantes :

L'option replica_pending_jobs_size_max définit la mémoire maximale, en octets, disponible pour les files d'attente contenant des événements qui ne sont pas encore appliqués.

Instance principale : options de réplication parallèle

Cloud SQL pour MySQL est compatible avec plusieurs options pour une utilisation sur une instance principale. Vous pouvez utiliser ces options pour régler les performances de réplication pour les instances dupliquées avec accès en lecture pour lesquelles la réplication parallèle est activée. Pour en savoir plus sur les options, cliquez sur les liens suivants vers la documentation MySQL 8.0 :

La modification de ces options ne redémarre pas l'instance principale.

Le tableau suivant contient les plages autorisées et les valeurs par défaut pour ces options :

Option de l'instance principale Valeurs autorisées MySQL 5.7 (valeur par défaut) MySQL 8.0 (valeur par défaut) MySQL 8.4 (valeur par défaut)
binlog_transaction_dependency_history_size 1-1000000 25 000 25 000 25 000
binlog_transaction_dependency_tracking COMMIT_ORDER, WRITESET, WRITESET_SESSION COMMIT_ORDER WRITESET N/A (obsolète dans MySQL 8.4)
transaction_write_set_extraction OFF, MURMUR32, XXHASH64 OFF XXHASH64 N/A (obsolète dans MySQL 8.4)

Dans MySQL 5.7, si binlog_transaction_dependency_tracking est défini sur WRITESET ou WRITESET_SESSION, transaction_write_set_extraction doit être défini sur une valeur non OFF (XXHASH64 ou MURMUR32).

Vérifier l'état de la duplication

Lorsque vous affichez une instance dupliquée à l'aide de Google Cloud Console ou que vous vous connectez à l'instance à l'aide d'un client d'administration, vous obtenez des informations sur la réplication, y compris l'état et les métriques. Si vous utilisez gcloud CLI, vous obtenez un bref résumé de la configuration de la réplication.

Avant de vérifier l'état de la réplication d'une instance dupliquée Cloud SQL, exécutez la commande
gcloud sql instances describe pour afficher l'état de l'instance. Vous pouvez ainsi vérifier si la réplication est activée pour l'instance dupliquée.

Les métriques suivantes sont disponibles pour les instances dupliquées. Apprenez-en plus sur les autres métriques disponibles pour l'ensemble des instances, y compris les instances non dupliquées.

MétriqueDescription
État de la réplication
(cloudsql.googleapis.com/database/replication/state)

Indique si la réplication diffuse activement les journaux de l'instance principale vers l'instance dupliquée. Les valeurs possibles sont les suivantes :

  • Running
  • Stopped
  • Error

Cette métrique indique Running si les threads d'E/S et SQL de l'instance dupliquée indiquent tous deux qu'ils sont en cours d'exécution. Consultez les métriques État d'exécution du thread d'E/S esclave et État d'exécution du thread SQL esclave ci-dessous, ou consultez la page Vérifier l'état de la réplication dans le manuel de référence MySQL.
Délai avant réplication
(cloudsql.googleapis.com/database/replication/replica_lag)

La durée de retard de l'instance dupliquée par rapport à l'état de l'instance principale. Cela correspond à la différence entre (1) l'heure actuelle et (2) l'horodatage d'origine auquel la transaction a été validée et qui est actuellement appliquée à l'instance répliquée. En particulier, si cette instance dupliquée n'a pas encore appliqué l'écriture dans la base de données, les écritures peuvent être comptabilisées comme étant en retard, même si elles ont été reçues par l'instance dupliquée.

Pour les instances répliquées en cascade, chaque paire instance principale/instance répliquée est surveillée séparément et il n'existe pas de métrique spécifique donnant le délai de bout en bout (de l'instance principale vers l'instance répliquée).

Cette métrique indique la valeur de Seconds_Behind_Master lorsque SHOW REPLICA STATUS est exécuté sur l'instance dupliquée. Pour en savoir plus, consultez la page Vérifier l'état de la réplication dans le manuel de référence MySQL.
Latence du réseau
(cloudsql.googleapis.com/database/replication/network_lag)

Durée, en secondes, nécessaire pour écrire le binlog dans la base de données principale et atteindre le thread d'E/S dans l'instance dupliquée.

Si la valeur "network_lag" est nulle ou négligeable, mais que la valeur "replica_lag" est élevée, cela signifie que le thread SQL ne peut pas appliquer les modifications de réplication suffisamment rapidement.
État d'exécution du thread d'E/S esclave
(cloudsql.googleapis.com/database/mysql/replication/slave_io_running_state)

Indique si le thread d'E/S pour la lecture du journal binaire de l'instance principale est en cours d'exécution sur l'instance dupliquée. Les valeurs possibles sont les suivantes :

  • Yes
  • No
  • Connecting

Cette métrique indique la valeur de Slave_IO_Running lorsque SHOW REPLICA STATUS est exécuté sur l'instance dupliquée. Pour en savoir plus, consultez la page Vérifier l'état de la réplication dans le manuel de référence MySQL.
État d'exécution du thread SQL esclave
(cloudsql.googleapis.com/database/mysql/replication/slave_sql_running_state)

Indique si le thread SQL permettant l'exécution des événements consignés dans le journal de relais est en cours d'exécution sur l'instance dupliquée. Les valeurs possibles sont les suivantes :

  • Yes
  • No
  • Connecting

Cette métrique indique la valeur de Slave_SQL_Running lorsque SHOW REPLICA STATUS est exécuté sur l'instance dupliquée. Pour en savoir plus, consultez la page Vérifier l'état de la réplication dans le manuel de référence MySQL.

Pour vérifier l'état de la réplication, procédez comme suit :

Console

Cloud SQL indique les métriques Replication State et Replication Lag dans le tableau de bord de surveillance Cloud SQL par défaut.

Pour afficher d'autres métriques liées aux instances dupliquées régionales et interrégionales, ainsi que les instances dupliquées des serveurs externes, créez un tableau de bord personnalisé et ajoutez-y les métriques que vous souhaitez surveiller :

  1. Dans Google Cloud Console, accédez à la page Monitoring.

    Accéder à Monitoring

  2. Sélectionnez l'onglet Tableaux de bord.
  3. Cliquez sur Créer un tableau de bord.
  4. Attribuez un nom au tableau de bord, puis cliquez sur OK.
  5. Cliquez sur Ajouter un graphique.
  6. Pour Type de ressource, sélectionnez Base de données Cloud SQL.
  7. Effectuez l'une des actions suivantes :
    1. Pour surveiller la métrique de l'état de réplication : saisissez Replication state dans le champ Sélectionner une métrique. Ensuite, ajoutez le filtre state = "Running". Le graphique indique 1 si la réplication est en cours, et 0 sinon.
    2. Pour surveiller la métrique du délai de réplication : saisissez replica_lag dans le champ Sélectionner une métrique. Le graphique montre la durée du retard de l'état de l'instance dupliquée par rapport à celui de son instance principale.
    3. Pour surveiller l'état du thread d'E/S de l'instance dupliquée : saisissez Slave I/O thread running state dans le champ Sélectionner une métrique. Ajoutez ensuite un filtre sur state = "Yes". Le graphique indique 1 si le thread est en cours d'exécution et 0 dans le cas contraire.
    4. Pour surveiller l'état du thread SQL de l'instance dupliquée : saisissez Slave SQL thread running state dans le champ Sélectionner une métrique. Ajoutez ensuite un filtre sur state = "Yes". Le graphique indique 1 si le thread est en cours d'exécution et 0 dans le cas contraire.

gcloud

Vous pouvez vérifier l'état de la réplication d'une instance dupliquée à l'aide de la commande suivante :

gcloud sql instances describe REPLICA_NAME

Dans le résultat, recherchez les propriétés databaseReplicationEnabled et masterInstanceName.

Vous pouvez vérifier si une instance maître possède des instances dupliquées à l'aide de la commande suivante :

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Dans le résultat, recherchez la propriété replicaNames.

Client mysql

  1. Connectez-vous à l'instance dupliquée à partir d'un client MySQL.

    Pour en savoir plus, consultez la page Options de connexion pour les applications externes.

  2. Vérifiez l'état de l'instance dupliquée : 
    SHOW REPLICA STATUS \G

    Recherchez les métriques suivantes dans le résultat de la commande :

    • Master_Host : nom de l'instance principale.
    • Slave_IO_Running et Slave_SQL_Running : indiquent respectivement si les threads d'E/S et SQL sont en cours d'exécution. Ces threads sont responsables du transfert des événements depuis le journal principal vers le journal de relais de l'instance dupliquée, ainsi que de l'exécution de ces événements à partir du journal de relais. La valeur de la métrique est Yes si le thread est en cours d'exécution. Les deux threads doivent être en cours d'exécution pour que la réplication soit active.
    • Seconds_Behind_Master : durée du retard, en secondes, dans le traitement par l'instance dupliquée des transactions de l'instance principale, c'est-à-dire la différence entre (1) l'heure actuelle et (2) l'horodatage d'origine auquel la transaction actuellement appliquée à l'instance dupliquée a été validée sur l'instance principale. La métrique vaut NULL si la réplication est interrompue.
    • Master_Log_file, Read_Master_Log_Pos, Relay_Master_Log_File, Exec_Master_Log_Pos : Ces métriques affichent les coordonnées (nom de fichier et décalage) jusqu'auxquelles le thread d'E/S dispose d'événements de lecture (Master_Log_file et Read_Master_Log_Pos) et jusqu'auxquelles le thread SQL a exécuté des événements (Relay_Master_Log_File et Exec_Master_Log_Pos). Si elles sont identiques (c'est-à-dire, Master_Log_file est égal à Relay_Master_Log_File et Read_Master_Log_Pos est égal à Exec_Master_Log_Pos), cela signifie que l'instance dupliquée a traité tous les événements qu'elle a reçus de l'instance principale.

Pour en savoir plus sur le résultat de cette commande, consultez la documentation MySQL sur la vérification de l'état de la réplication.

Résoudre les problèmes

Problème Dépannage
L'instance répliquée avec accès en lecture n'a pas commencé à se répliquer lors de la création. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue. L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'une option que vous avez explicitement définie ou d'une option définie sur une valeur par défaut.

Tout d'abord, vérifiez que la valeur de l'option max_connections est supérieure ou égale à la valeur principale.

Si l'option max_connections est définie correctement, inspectez les journaux dans Cloud Logging pour rechercher l'erreur réelle.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.

Si l'erreur est : set Service Networking service account as servicenetworking.serviceAgent role on consumer project, désactivez et réactivez Service Networking API. Cette action crée le compte de service nécessaire pour poursuivre le processus.
Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque.
L'instance dupliquée utilise trop de mémoire. L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale.

Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
La duplication s'est arrêtée. La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée.

Modifiez l'instance pour activer automatic storage increase.
Le délai de duplication est systématiquement long. La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication :
  • Requêtes lentes sur l'instance dupliquée. Recherchez-les et corrigez-les.
  • Toutes les tables doivent avoir une clé unique/primaire. Chaque mise à jour d'une table sans clé unique/primaire entraîne une analyse complète des tables de l'instance répliquée.
  • Les requêtes telles que DELETE ... WHERE field < 50000000 allongent le délai de duplication, dans le cas des duplications basées sur les lignes, car un grand nombre de mises à jour s'accumulent sur l'instance dupliquée.

Voici quelques solutions possibles :
Le délai de réplication augmente soudainement. Ce problème est causé par des transactions de longue durée. Lorsqu'une transaction (une ou plusieurs instructions) est validée sur l'instance source, l'heure de début de la transaction est enregistrée dans le journal binaire. Lorsque l'instance répliquée reçoit cet événement binlog, elle compare ce code temporel au code temporel actuel pour calculer le délai de réplication. Par conséquent, une transaction de longue durée sur la source entraîne un délai de réplication important immédiat sur l'instance dupliquée. Si la quantité de modifications de ligne dans la transaction est importante, l'instance dupliquée prendra également beaucoup de temps à l'exécuter. Pendant ce temps, le délai de réplication augmente. Une fois que l'instance dupliquée a terminé cette transaction, la période de rattrapage dépend de la charge de travail d'écriture sur la source et de la vitesse de traitement de l'instance dupliquée.

Voici quelques solutions possibles pour éviter une longue transaction :

  • Diviser la transaction en plusieurs petites transactions
  • Fragmenter une seule requête d'écriture volumineuse en lots plus petits
  • Tenter de séparer les longues requêtes SELECT d'une transaction associée à des LMD
La modification des options de réplication parallèle génère une erreur. Une valeur incorrecte est définie pour une ou plusieurs de ces options.

Sur l'instance principale qui affiche le message d'erreur, définissez les options de réplication parallèle comme suit :

  1. Modifiez les options binlog_transaction_dependency_tracking et transaction_write_set_extraction :
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Ajoutez l'option slave_pending_jobs_size_max :

    slave_pending_jobs_size_max=33554432

  3. Modifiez l'option transaction_write_set_extraction :

    transaction_write_set_extraction=XXHASH64

  4. Modifiez l'option binlog_transaction_dependency_tracking :

    binlog_transaction_dependency_tracking=WRITESET
La création d'une instance dupliquée échoue avec un délai d'expiration. Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture.

Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution.

Étape suivante