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

Cette page décrit le processus de configuration de la réplication de serveurs externes à l'aide d'une importation personnalisée. Ces étapes sont la meilleure option lorsque vous devez répliquer à partir d'une grande base de données externe.

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 dupliquée de la même manière que n'importe quelle autre instance Cloud SQL.

Ce processus n'est possible que pour les serveurs externes configurés pour utiliser la réplication basée sur l'identifiant de transaction global (GTID). Avant de lancer la réplication, vous devez charger les données depuis le serveur externe dans l'instance dupliquée Cloud SQL. Si vous n'utilisez pas la réplication basée sur GTID, Cloud SQL ne peut pas identifier la position exacte du journal binaire à partir de laquelle démarrer la réplication. Si vous ne pouvez pas utiliser la réplication basée sur GITD, vous devez configurer votre outil de vidage pour établir un verrouillage global en lecture seule pendant le processus de vidage.

Avant de commencer

Avant de commencer, vous devez avoir configuré le serveur externe, créé l'instance de représentation source et configuré l'instance dupliquée Cloud SQL.

Mettre à jour les autorisations pour l'utilisateur de réplication

L'utilisateur de réplication sur le serveur externe 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. Ouvrez un terminal sur le serveur de base de données source, puis saisissez les commandes suivantes :

Client mysql

    UPDATE mysql.user
    SET Host='NEW_HOST' WHERE Host='OLD_HOST' AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE 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 ON *.*
TO 'gcp_user'@'gmail.com';
FLUSH PRIVILEGES;
Valeur 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 du compte utilisateur GCP.
HOST Nom d'hôte du compte utilisateur GCP.

Configurer l'instance dupliquée Cloud SQL en tant qu'instance principale

Les instances dupliquées Cloud SQL sont en lecture seule. Pour effectuer une importation personnalisée, vous devez promouvoir l'instance dupliquée Cloud SQL en instance autonome. Une fois l'importation initiale des données terminée, vous rétrogradez l'instance vers une instance dupliquée.

Effectuer un vidage et une importation personnalisés

Dans cette section, nous vous expliquons comment créer le fichier de vidage et l'importer dans l'instance dupliquée Cloud SQL à l'aide de mydumper ou des utilitaires clients mysqldump.

Lorsque vous videz les données, vous devrez peut-être exclure les bases de données génériques MySQL, y compris mysql et sys, si elles existent sur l'instance source. Sinon, l'importation des données échoue. Consultez la section Comment exclure (ou inclure) des bases de données.

Utiliser mydumper et myloader

Pour créer un fichier de vidage et l'importer dans Cloud SQL, procédez comme suit :

  1. Créez un fichier de vidage de la base de données du serveur externe à l'aide de mydumper.

       $ mydumper -u USERNAME -p PASSWORD \
                  --threads=16 -o ./backup \
                  -h HOST \
                  --no-locks \
                  --regex '^(?!(mysql\.|sys\.))'
    
    Valeur Description
    USERNAME Nom du compte utilisateur de réplication ou du compte utilisateur sur le serveur externe disposant des autorisations de lecture sur la base de données.
    PASSWORD Mot de passe utilisateur de la réplication.
    HOST Adresse IPv4 ou DNS du serveur externe.
  2. Importez les données dans l'instance Cloud SQL à l'aide de myloader.

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
                --threads=16 \
                -d ./backup -h HOST -o
    
    Valeur Description
    REPLICA_USERNAME Compte utilisateur sur l'instance Cloud SQL.
    REPLICA_PASSWORD Mot de passe de l'utilisateur de l'instance Cloud SQL.
    HOST Adresse IPv4 de l'instance Cloud SQL.
  3. Notez les informations GTID ou du binlog du vidage des données. Vous avez besoin de ces informations lors de la configuration de la réplication avec les procédures stockées.

    Pour obtenir les informations GTID ou du binlog du vidage des données, exécutez la commande suivante:

      sudo cat ./backup/metadata
    

Utiliser mysqldump

  1. Créez un vidage à l'aide de mysqldump :

    mysqldump

    mysqldump \
        --host=EXTERNAL_HOST \
        --port=EXTERNAL_PORT \
        --user=USERNAME\
        --password=PASSWORD \
        --databases=DATABASE_LIST  \
        --hex-blob \
        --master-data=EXTERNAL_DATA  \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        GTID_PURGED \
        ADD_DROP_TABLE \
        ROUTINES \
        COMPRESS \
        GZIP
    
    Valeur Description
    EXTERNAL_HOST Adresse IPv4 ou DNS du serveur externe.
    EXTERNAL_PORT Port du serveur externe. Si le serveur externe est hébergé sur Cloud SQL, il s'agit de 3306.
    USERNAME Nom du compte utilisateur de réplication ou du compte utilisateur sur le serveur externe disposant des autorisations de lecture sur la base de données.
    USER_PASSWORD Mot de passe utilisateur de la réplication.
    DATABASE_LIST Liste de toutes les bases de données du serveur externe, séparées par des espaces, à l'exception des bases de données système (sys, mysql, performance_schema et information_schema). Utilisez la commande MySQL SHOW DATABASES pour répertorier vos bases de données.
    EXTERNAL_DATA Si votre serveur externe n'est pas compatible avec GTID et que vous êtes autorisé à accéder au verrouillage global en lecture, utilisez --master-data=1. Sinon, n'utilisez pas cette propriété.
    GTID_PURGED Si votre serveur externe est compatible avec GTID, utilisez --set-gtid-purged=on. Sinon, n'utilisez pas cette propriété.
    ADD_DROP_TABLE Si vous souhaitez ajouter une instruction DROP TABLE avant chaque instruction CREATE TABLE, ajoutez --add-drop-table.
    ROUTINES Si vous souhaitez afficher les routines stockées, telles que les procédures et les fonctions, dans le résultat des bases de données vidées, incluez --routines.
    COMPRESS Si vous souhaitez compresser toutes les informations envoyées entre l'instance dupliquée Cloud SQL et le serveur externe, utilisez --compress.
    GZIP Si vous souhaitez compresser davantage le fichier de vidage, utilisez | gzip. Si votre base de données contient des données qui sont difficiles à compresser, telles que des données incompressibles binaires ou des images JPG, ne l'utilisez pas.

    exemple

    
    mysqldump \
        --host=192.0.2.1 \
        --port=3306 \
        --user=replicationUser \
        --password \
        --databases guestbook journal \
        --hex-blob \
        --master-data=1 \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        --compress \
        | gzip
    
  2. Notez les informations GTID ou du binlog du vidage des données. Vous avez besoin de ces informations pour configurer la réplication avec les procédures stockées Cloud SQL.

    Pour le GTID, recherchez une ligne semblable à celle-ci :

       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
    

    Pour le binlog, recherchez une ligne semblable à celle-ci :

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
    
  3. Supprimez les lignes suivantes du fichier de vidage qui nécessitent des super-droits. Étant donné que les utilisateurs de Cloud SQL ne disposent pas de super-droits, ces lignes entraînent l'échec de l'importation.

    Pour la réplication basée sur GTID : supprimez l'instruction SET GTID_PURGED ainsi que l'instruction du paramètre de variable de session dans le fichier de vidage. Exemple :

       ...
       SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
       SET @@SESSION.SQL_LOG_BIN= 0;
       ...
       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
       ...
       SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;
    

    Pour la réplication basée sur le binlog, supprimez l'instruction CHANGE MASTER. Exemple :

       ...
       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
        ...
    
  4. Importez les données dans l'instance dupliquée Cloud SQL à l'aide de la CLI mysql :

    mysql

    mysql -h REPLICA_HOST -u REPLICA_USER \
    -p REPLICA_DATABASE_NAME RESULT_FILE
    
    Valeur Description
    REPLICA_HOST Hôte sur lequel se trouve le serveur MySQL.
    REPLICA_USER Nom d'utilisateur MySQL à utiliser lors de la connexion au serveur.
    REPLICA_DATABASE_NAME Nom de la base de données dans laquelle se trouvent les données.
    RESULT_FILE Nom du fichier de vidage à importer.

    exemple

      mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql
    

Vous pouvez également importer le fichier de vidage à l'aide d'un bucket Google Cloud. Consultez la page Importer des données à partir d'un fichier de vidage SQL dans Cloud SQL.

Rétrograder l'instance Cloud SQL

Pour rétrograder l'instance Cloud SQL en instance dupliquée Cloud SQL, appliquez la méthode demoteMaster sur l'instance.

  1. Préparez un fichier JSON de requête avec le nom de l'instance que vous souhaitez rétrograder.

    Source JSON

     {
        "demoteMasterContext": {
          "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
          "skipReplicationSetup": true
          }
     }
    
    Valeur Description
    SOURCE_REPRESENTATION_INSTANCE_NAME Nom de l'instance de représentation source.

    exemple

       {
         "demoteMasterContext": {
           "masterInstanceName": "cloudsql-source-instance",
           "skipReplicationSetup": true
         }
       }
    
  2. Ouvrez un terminal et utilisez les commandes suivantes pour appeler demoteMaster :

    curl

      gcloud auth login
      ACCESS_TOKEN="$(gcloud auth print-access-token)"
      curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
        --header 'Content-Type: application/json' \
        --data @JSON_PATH \
        -X POST \
      https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE-NAME/demoteMaster
    
    Valeur Description
    JSON_PATH Chemin d'accès au fichier JSON.
    PROJECT_ID ID de votre projet dans Google Cloud.
    INSTANCE-NAME Nom de l'instance à rétrograder.

    exemple

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

Ce qui doit s'afficher à la fin du processus

Pour vous assurer que vos instances ont été correctement configurées, accédez à la page Instances Cloud SQL.

Vous devriez voir votre instance de représentation source et votre instance dupliquée Cloud SQL. Ces lignes se présentent comme ceci :

ID d'instance Type Adresse IP publique
(-) source-representation-instance Instance principale externe MySQL 10.68.48.3:3306
replica-instance Instance dupliquée avec accès en lecture MySQL 34.66.48.59

Démarrer la réplication sur l'instance Cloud SQL

Cette étape utilise les procédures stockées Cloud SQL. Les procédures stockées Cloud SQL sont installées après avoir appelé la requête demoteMaster. Elles sont supprimées après l'appel de promoteReplica. Pour plus d'informations, consultez la section Procédures stockées pour la gestion de la réplication.

  1. Connectez-vous à l'instance dupliquée. Pour en savoir plus, consultez la section Se connecter à l'aide d'un client de base de données depuis un ordinateur local.
  2. Utilisez la procédure stockée mysql.resetMaster pour réinitialiser les paramètres de réplication.

     mysql> call mysql.resetMaster();
    
  3. Configurez la réplication. Cette étape nécessite les informations GTID ou binlog que vous avez précédemment écrites.

    GTID

    1. Configurez le champ gtid_purged avec la procédure stockée mysql.skipTransactionWithGtid(GTID_TO_SKIP).
    Valeur Description
    GTID_TO_SKIP Valeur de l'ensemble GTID à configurer.

    Exemple :

        mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');
    

    1. Exécutez la procédure stockée mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).
    Valeur Description
    HOST Point de terminaison source.
    PORT Port source
    USER_NAME Utilisateur source.
    USER_PASSWORD Mot de passe de l'utilisateur source.
    MASTER_AUTO_POSITION Valeur du paramètre master_auto_position. Les valeurs possibles sont 0, 1.
    USE_SSL Indiquez s'il faut utiliser la réplication basée sur SSL. Les valeurs possibles sont les suivantes true, false. Si true, vous devez définir le champ caCertificate dans la requête DemoteMaster.
    USE_SSL_CLIENT_AUTH Indiquez s'il faut utiliser l'authentification du client SSL. Les valeurs possibles sont les suivantes true, false. Si true, vous devez définir les champs clientKey et clientCertificates dans la requête demoteMaster.
        mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
        'USERNAME', 'PASSWORD', \
        /* master_auto_position= */ 1,false, false); \
    

    binlog

    Exécutez la procédure stockée mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH).

    Valeur Description
    HOST Point de terminaison source.
    PORT Port source
    USER_NAME Utilisateur source.
    USER_PASSWORD Mot de passe de l'utilisateur source.
    SOURCE_LOG_NAME Nom du journal binaire sur l'instance de base de données source contenant les informations de réplication.
    SOURCE_LOG_POS Emplacement dans le journal binaire mysql_binary_log_file_name à partir duquel la réplication commence à lire les informations de réplication.
    USE_SSL Indiquez s'il faut utiliser la réplication basée sur SSL. Les valeurs possibles sont les suivantes true, false. Si true, vous devez définir le champ caCertificate dans la requête DemoteMaster.
    USE_SSL_CLIENT_AUTH Indiquez s'il faut utiliser l'authentification du client SSL. Les valeurs possibles sont les suivantes true, false. Si true, vous devez définir les champs clientKey et clientCertificates dans la requête demoteMaster.
        mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
        'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
        false, false);
    
  4. Utilisez la procédure stockée mysql.startReplication() pour démarrer la réplication à partir de la base de données externe.

       mysql> call mysql.startReplication();
    
  5. Vérifiez l'état de la réplication. Assurez-vous que les champs Slave_IO_Running et Slave_SQL_Running affichent YES.

       mysql> show slave status\G
    

    Le résultat de la commande ressemble à ceci :

       *************************** 1. row ***************************
                       Slave_IO_State: Waiting for master to send event
                          Master_Host: 1.1.1.1
                          Master_User: user_name
                          Master_Port: 3306
                        Connect_Retry: 60
                      Master_Log_File: mysql-bin-changelog.000001
                  Read_Master_Log_Pos: 1
                       Relay_Log_File: relay-log.000002
                        Relay_Log_Pos: 1
                Relay_Master_Log_File: mysql-bin-changelog.000001
                     Slave_IO_Running: Yes
                    Slave_SQL_Running: Yes
                      Replicate_Do_DB:
                  Replicate_Ignore_DB:
                   Replicate_Do_Table:
               Replicate_Ignore_Table:
              Replicate_Wild_Do_Table:
          Replicate_Wild_Ignore_Table: mysql.%
                           Last_Errno: 0
                           Last_Error:
                         Skip_Counter: 0
                  Exec_Master_Log_Pos: 412
                      Relay_Log_Space: 752
                      Until_Condition: None
                       Until_Log_File:
                        Until_Log_Pos: 0
                   Master_SSL_Allowed: No
                   Master_SSL_CA_File:
                   Master_SSL_CA_Path:
                      Master_SSL_Cert:
                    Master_SSL_Cipher:
                       Master_SSL_Key:
                Seconds_Behind_Master: 0
        Master_SSL_Verify_Server_Cert: No
                        Last_IO_Errno: 0
                        Last_IO_Error:
                       Last_SQL_Errno: 0
                       Last_SQL_Error:
          Replicate_Ignore_Server_Ids:
                     Master_Server_Id: 1509941531
                          Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f
                 Master_Info_File: mysql.slave_master_info
                        SQL_Delay: 0
              SQL_Remaining_Delay: NULL
          Slave_SQL_Running_State: Slave has read all r
               Master_Retry_Count: 86400
                      Master_Bind:
          Last_IO_Error_Timestamp:
         Last_SQL_Error_Timestamp:
                   Master_SSL_Crl:
               Master_SSL_Crlpath:
               Retrieved_Gtid_Set:
                Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226
                    Auto_Position: 0
       1 row in set (0.00 sec)
    

Procéder à la réplication

Une fois que vous avez démarré la réplication à partir du serveur externe, vous devez surveiller la réplication, puis terminer la migration. Pour en savoir plus, consultez la section Surveiller la réplication.

Résoudre les problèmes

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 dupliquée dans la section "Cloud Monitoring" de Google Cloud Console.
  • 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 dupliqué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