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;
| 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 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 :
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\.))'
Propriété 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. 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
Propriété 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. 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
Créez un vidage à l'aide de
mysqldump:mysqldumpmysqldump \ --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
Propriété 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_schemaetinformation_schema). Utilisez la commande MySQLSHOW DATABASESpour 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 TABLEavant chaque instructionCREATE 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 dump, 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
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;
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; ...
Importez les données dans l'instance dupliquée Cloud SQL à l'aide de la CLI
mysql:mysqlmysql -h REPLICA_HOST -u REPLICA_USER \ -p REPLICA_DATABASE_NAME RESULT_FILE
Propriété 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.
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 } }
Propriété Description SOURCE_REPRESENTATION_INSTANCE_NAME Nom de l'instance de représentation source. exemple
{ "demoteMasterContext": { "masterInstanceName": "cloudsql-source-instance", "skipReplicationSetup": true } }
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
Propriété 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.
- 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.
Utilisez la procédure stockée
mysql.resetMasterpour réinitialiser les paramètres de réplication.mysql> call mysql.resetMaster();
Configurez la réplication. Cette étape nécessite les informations GTID ou binlog que vous avez précédemment écrites.
GTID
- Configurez le champ
gtid_purgedavec la procédure stockéemysql.skipTransactionWithGtid(GTID_TO_SKIP).
Propriété Description GTID_TO_SKIP Valeur de l'ensemble GTID à configurer. Exemple :
mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');
- Exécutez la procédure stockée
mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).
Propriété 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 sont0,1.USE_SSL Indiquez s'il faut utiliser la réplication basée sur SSL. Les valeurs possibles sont les suivantes true,false. Sitrue, vous devez définir le champcaCertificatedans la requêteDemoteMaster.USE_SSL_CLIENT_AUTH Indiquez s'il faut utiliser l'authentification du client SSL. Les valeurs possibles sont les suivantes true,false. Sitrue, vous devez définir les champsclientKeyetclientCertificatesdans la requêtedemoteMaster.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).Propriété 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. Sitrue, vous devez définir le champcaCertificatedans la requêteDemoteMaster.USE_SSL_CLIENT_AUTH Indiquez s'il faut utiliser l'authentification du client SSL. Les valeurs possibles sont les suivantes true,false. Sitrue, vous devez définir les champsclientKeyetclientCertificatesdans la requêtedemoteMaster.mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \ 'user_name', 'password', 'mysql-bin-changelog.033877', 360, \ false, false);
- Configurez le champ
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();
Vérifiez l'état de la réplication. Assurez-vous que les champs
Slave_IO_RunningetSlave_SQL_RunningaffichentYES.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 |
| 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 Exécutez la commande |
| 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
|
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 :
Accédez à la visionneuse de journaux dans Google Cloud Console.
- Sélectionnez l'instance répliquée Cloud SQL dans la liste déroulante Instance.
- 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
- Apprenez-en plus sur la mise à jour des instances.
- Apprenez-en plus sur la gestion des instances dupliquées.
- Apprenez-en plus sur la surveillance des instances.
- Découvrez comment promouvoir votre instance dupliquée Cloud SQL afin de promouvoir l'instance dupliquée en instance autonome et d'arrêter la réplication à partir du serveur externe.