Utiliser une importation gérée pour configurer la réplication à partir de bases de données externes

Cette page explique comment configurer et utiliser une importation gérée pour les données lors de la réplication d'un serveur externe vers Cloud SQL.

Vous devez suivre intégralement la procédure présentée sur cette page. Lorsque vous avez terminé, vous pouvez administrer et surveiller l'instance de représentation source de la même manière que toute autre instance Cloud SQL.

Avant de commencer

Avant de commencer, effectuez les étapes suivantes :

  1. Configurez le serveur externe.

  2. Créez l'instance de représentation source.

  3. Configurez l'instance dupliquée Cloud SQL.

Mettre à jour les droits de l'utilisateur de réplication

L'utilisateur de réplication sur le serveur de base de données source est configuré pour accepter les connexions provenant de n'importe quel hôte (%). Vous devez mettre à jour ce compte utilisateur afin qu'il ne puisse être utilisé qu'avec l'instance dupliquée Cloud SQL.

Droits requis

Il existe quatre types de combinaisons de migrations et de vidages.

  • Type 1 : migration continue et vidage géré
  • Type 2 : migration continue et vidage manuel
  • Type 3 : migration unique et vidage géré
  • Type 4 : migration unique et vidage manuel

Les droits pour chaque type de combinaison de migration et de vidage sont listés ci-dessous.

Type 1

Le compte utilisateur doit disposer des droits suivants :

Pour MySQL version 8.0 ou ultérieure, il est recommandé d'ignorer le droit BACKUP ADMIN pour des performances optimales.

Type 2

Le compte utilisateur doit disposer des droits suivants :

Type 3

Le compte utilisateur doit disposer des droits suivants :

Pour MySQL version 8.0 ou ultérieure, il est recommandé d'ignorer le droit BACKUP ADMIN pour des performances optimales.

Type 4

Aucun droit n'est requis.

Mettre à jour les droits

Pour mettre à jour les droits, ouvrez un terminal sur le serveur externe, puis saisissez les commandes suivantes.

Client mysql

Pour GTID : 

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Pour le binlog : 

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

exemple

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;
Propriété Description
NEW_HOST Indiquez l'adresse IP sortante de l'instance dupliquée Cloud SQL.
OLD_HOST Valeur actuelle attribuée à Host que vous souhaitez modifier.
USERNAME Compte utilisateur de réplication sur le serveur externe.
GCP_USERNAME Nom d'utilisateur pour le compte utilisateur.
HOST Nom d'hôte pour le compte utilisateur.

Vérifier les paramètres de réplication

Une fois la configuration terminée, assurez-vous que l'instance dupliquée Cloud SQL peut effectuer la réplication à partir du serveur externe.

Les paramètres de synchronisation externe suivants doivent être corrects.

  • La connectivité entre l'instance dupliquée Cloud SQL et le serveur externe
  • Les privilèges de l'utilisateur de réplication
  • Compatibilité des versions
  • L'instance dupliquée Cloud SQL n'est pas déjà en cours de réplication
  • Les binlogs sont activés sur le serveur externe
  • GTID est activé si vous essayez d'effectuer une synchronisation externe à partir d'un serveur externe RDS et que vous utilisez un bucket Google Cloud

Pour vérifier ces paramètres, ouvrez un terminal Cloud Shell et saisissez les commandes suivantes :

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

exemple

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

exemple avec options de synchronisation 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Ces appels renvoient une liste de type sql#externalSyncSettingErrorList.

Si la liste est vide, aucune erreur ne s'affiche. Une réponse sans erreur s'affiche comme suit :

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
Propriété Description
SYNC_MODE Assurez-vous que l'instance répliquée Cloud SQL et le serveur externe sont synchronisés après la configuration de la réplication. Les modes de synchronisation incluent EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE et OFFLINE.
SYNC_PARALLEL_LEVEL

Vérifiez le paramètre qui contrôle la vitesse à laquelle les données des tables d'une base de données sont transférées. Les valeurs suivantes sont disponibles :

  • min: utilise la plus faible quantité de ressources de calcul sur la base de données. Il s'agit de la vitesse la plus lente pour transférer des données.
  • optimal: offre des performances équilibrées avec une charge optimale sur la base de données.
  • max: fournit la vitesse la plus élevée pour le transfert de données, mais cela peut entraîner une charge accrue sur la base de données.

Remarque : La valeur par défaut de ce paramètre est optimal, car elle offre une vitesse de transfert des données satisfaisante et a un impact raisonnable sur la base de données. Nous vous recommandons d'utiliser cette valeur.
SYNC_FLAGS Liste des options de synchronisation initiale à vérifier. Recommandé uniquement si vous prévoyez d'utiliser des options de synchronisation personnalisées lors de la réplication à partir de la source. Pour consulter la liste des options autorisées, consultez la section Options de synchronisation initiale.
PROJECT_ID L'ID de votre projet Google Cloud.
REPLICA_INSTANCE_ID ID de votre instance dupliquée Cloud SQL.

Autorisation globale de verrouillage en lecture

Si vous n'êtes pas autorisé à accéder au verrouillage global en lecture sur le serveur externe, comme cela pourrait être le cas avec Amazon RDS ou Amazon Aurora, vous devez suspendre les écritures sur votre serveur, comme décrit dans la procédure ci-dessous :

  1. Accédez à l'explorateur de journaux, puis sélectionnez votre instance dupliquée Cloud SQL dans la liste des ressources. Une liste des journaux les plus récents pour votre instance dupliquée Cloud SQL devrait s'afficher. Ignorez-les pour le moment.
  2. Ouvrez un terminal, puis saisissez les commandes de la section Démarrer la réplication sur le serveur externe pour effectuer la réplication à partir du serveur externe.

  3. Revenez à l'explorateur de journaux. Lorsque le journal ci-dessous s'affiche, désactivez l'écriture dans la base de données sur votre serveur externe. Dans la plupart des cas, cette opération n'est requise que pendant quelques secondes.

       DUMP_IMPORT(START): Start importing data, please pause any write to the
   external primary database.

  4. Une fois que l'entrée de journal suivante s'affiche dans l'explorateur de journaux, réactivez l'écriture dans la base de données sur votre serveur externe.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
   external primary may resume.

Démarrer la réplication sur le serveur externe

Après avoir vérifié que vous pouvez répliquer à partir du serveur externe, démarrez la réplication. La vitesse de réplication pour le processus d'importation initial peut atteindre 500 Go par heure. Cependant, cette vitesse peut varier en fonction du niveau de machine, de la taille du disque de données, du débit du réseau et de la nature de votre base de données.

Au cours du processus d'importation initial, n'effectuez aucune opération LDD sur le serveur externe. Cela pourrait entraîner des incohérences lors de l'importation. Une fois le processus d'importation terminé, l'instance dupliquée utilise les journaux binaires sur le serveur externe pour récupérer l'état actuel de celui-ci.

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

exemple

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

exemple avec options de synchronisation 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
Propriété Description
SYNC_MODE Vérifiez que l'instance répliquée Cloud SQL et le serveur externe sont synchronisés après la configuration de la réplication.
SKIP_VERIFICATION Indique si l'étape de validation intégrée doit être ignorée avant de synchroniser vos données. Ce paramètre n'est recommandé que si vous avez déjà validé vos paramètres de réplication.
SYNC_PARALLEL_LEVEL

Indiquez un paramètre qui contrôle la vitesse à laquelle les données des tables d'une base de données sont transférées. Les valeurs suivantes sont disponibles :

  • min: utilise la plus faible quantité de ressources de calcul sur la base de données. Il s'agit de la vitesse la plus lente pour transférer des données.
  • optimal: offre des performances équilibrées avec une charge optimale sur la base de données.
  • max: fournit la vitesse la plus élevée pour le transfert de données, mais cela peut entraîner une charge accrue sur la base de données.

Remarque : La valeur par défaut de ce paramètre est optimal, car elle offre une vitesse de transfert des données satisfaisante et a un impact raisonnable sur la base de données. Nous vous recommandons d'utiliser cette valeur.
SYNC_FLAGS Liste des options de synchronisation initiale à vérifier. Recommandé uniquement si vous prévoyez d'utiliser des options de synchronisation personnalisées lors de la réplication à partir de la source. Pour consulter la liste des options autorisées, consultez la section Options de synchronisation initiale.
PROJECT_ID L'ID de votre projet Google Cloud.
REPLICA_INSTANCE_ID ID de votre instance dupliquée Cloud SQL.

Options de synchronisation initiale

Pour effectuer une migration avec des options de base de données personnalisées, vous pouvez utiliser les options autorisées suivantes :

  • --add-drop-database
  • --add-drop-table
  • --add-drop-trigger
  • --add-locks
  • --allow-keywords
  • --all-tablespaces
  • --apply-slave-statements
  • --column-statistics
  • --comments
  • --compact
  • --compatible
  • --complete-insert
  • --compress
  • --compression-algorithms
  • --create-options
  • --default-character-set
  • --delayed-insert
  • --disable-keys
  • --dump-date
  • --events
  • --extended-insert
  • --fields-enclosed-by
  • --fields-escaped-by
  • --fields-optionally-enclosed-by
  • --fields-terminated-by
  • --flush-logs
  • --flush-privileges
  • --force
  • --get-server-public-key
  • --hex-blob
  • --ignore-error
  • --ignore-read-lock-error
  • --ignore-table
  • --insert-ignore
  • --lines-terminated-by
  • --lock-all-tables
  • --lock-tables
  • --max-allowed-packet
  • --net-buffer-length
  • --network-timeout
  • --no-autocommit
  • --no-create-db
  • --no-create-info
  • --no-data
  • --no-defaults
  • --no-set-names
  • --no-tablespaces
  • --opt
  • --order-by-primary
  • --pipe
  • --quote-names
  • --quick
  • --replace
  • --routines
  • --secure-auth
  • --set-charset
  • --shared-memory-base-name
  • --show-create-skip-secondary-engine
  • --skip-opt
  • --ssl-cipher
  • --ssl-fips-mode
  • --ssl-verify-server-cert
  • --tls-ciphersuites
  • --tls-version
  • --triggers
  • --tz-utc
  • --verbose
  • --xml
  • --zstd-compression-level

Pour connaître les valeurs autorisées, consultez la documentation publique de MySQL.

Surveillez la migration.

Une fois la réplication lancée à partir du serveur externe, vous devez surveiller la réplication. Pour en savoir plus, consultez la section Surveiller la réplication. Vous pouvez ensuite terminer votre migration.

Résoudre les problèmes

Envisagez les options de dépannage suivantes :

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.

En outre, pour MySQL, envisagez également les options suivantes :

Problème Dépannage
Lost connection to MySQL server during query when dumping table. Peut-être que la source est devenue indisponible ou que le vidage contenait des paquets trop volumineux.

Assurez-vous que l'instance principale externe est disponible. Vous pouvez également modifier les valeurs des options net_read_timeout et net_write_timeout sur l'instance source afin d'arrêter l'erreur. Pour en savoir plus sur les valeurs autorisées pour ces options, consultez la page Configurer des options de base de données.

Pour en savoir plus sur l'utilisation des options de mysqldump pour la migration des importations gérées, consultez la section Options de synchronisation initiales autorisées et par défaut.
La migration initiale des données a abouti, mais aucune donnée n'est répliquée. Il se peut que votre base de données source ait défini des options de réplication qui empêchent la réplication de certaines ou de toutes les modifications de la base de données.

Assurez-vous que les options de réplication telles que binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db ne sont pas définies de manière conflictuelle.

Exécutez la commande show master status sur l'instance principale pour afficher les paramètres actuels.
La migration initiale des données a abouti, mais la réplication des données cesse de fonctionner après un certain temps. Solutions possibles

  • Vérifiez les métriques de réplication de votre instance répliquée dans la section "Cloud Monitoring" de la console Google Cloud.
  • Les erreurs du thread d'E/S MySQL ou du thread SQL sont disponibles dans Cloud Logging dans les fichiers mysql.err log.
  • Cette erreur peut également se produire lors de la connexion à l'instance dupliquée. Exécutez la commande SHOW SLAVE STATUS et vérifiez les champs suivants dans le résultat :
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. Le disque de données de l'instance dupliquée est saturé.

Augmentez la taille du disque de l'instance dupliquée. Vous pouvez augmenter manuellement la taille du disque ou activer l'augmentation automatique de l'espace de stockage.

Examiner vos journaux de réplication

Lorsque vous vérifiez les paramètres de réplication, des journaux sont générés.

Pour afficher ces journaux, procédez comme suit :

  1. Accédez à la visionneuse de journaux dans Google Cloud Console.

    Accéder à la visionneuse de journaux

  2. Sélectionnez l'instance répliquée Cloud SQL dans la liste déroulante Instance.
  3. Sélectionnez le fichier journal replication-setup.log.

Si l'instance dupliquée Cloud SQL ne parvient pas à se connecter au serveur externe, vérifiez les points suivants :

  • Tous les pare-feu du serveur externe sont configurés pour autoriser les connexions à partir de l'adresse IP sortante de l'instance dupliquée Cloud SQL.
  • Votre configuration SSL/TLS est correcte.
  • Votre utilisateur de réplication, hôte et mot de passe sont corrects.

Étape suivante