Google Cloud SQL pour MySQL est un service de base de données entièrement géré qui vous aide à configurer, maintenir, gérer et administrer vos bases de données relationnelles MySQL sur Google Cloud Platform. Cependant, il existe des différences entre Cloud SQL et les fonctionnalités MySQL standard, telles qu'un contrôle limité, des ressources restreintes, la localisation des données, le budget et la sécurité, qui peuvent influencer votre décision finale de quitter les instances Google Cloud SQL et d'héberger le service de base de données dans l'infrastructure des locaux à la place.
Cet article de blog vous expliquera comment effectuer une migration en ligne de Google Cloud SQL vers un serveur sur site. Notre base de données cible sur le serveur sur site est un serveur Debian, mais les étapes et procédures s'appliquent sur les autres versions de Linux aussi longtemps que les packages sont correctement installés.
Notre instance Google Cloud MySQL s'exécute sur MySQL 5.7 et nous avons besoin :
- Un utilisateur esclave de réplication créé sur le maître.
- L'esclave doit être installé avec la même version majeure que le maître.
- SSL doit être activé pour la réplication géographique pour des raisons de sécurité.
Étant donné que Google Cloud a activé par défaut la réplication GTID pour MySQL, nous allons effectuer une migration basée sur ce schéma de réplication. Par conséquent, les instructions décrites dans cet article devraient également fonctionner dans les instances MySQL 8.0.
Création d'un utilisateur esclave de réplication
Tout d'abord, nous devons créer un utilisateur esclave de réplication sur notre instance Google Cloud SQL. Connectez-vous à Google Cloud Platform -> Bases de données -> SQL -> sélectionnez l'instance MySQL -> Utilisateurs -> Ajouter un compte utilisateur et saisissez les informations requises :
Le 202.187.194.255 est l'adresse IP publique esclave située dans notre sur- locaux qui va répliquer à partir de cette instance. Comme vous pouvez le voir, il n'y a pas de configuration de privilèges puisque les utilisateurs créés à partir de cette interface auront les privilèges les plus élevés que Google Cloud SQL peut offrir (presque tout sauf SUPER et FILE). Pour vérifier les privilèges, nous pouvons utiliser la commande suivante :
mysql> SHOW GRANTS FOR [email protected]\G
*************************** 1. row ***************************
Grants for [email protected]: GRANT SELECT, INSERT, UPDATE, DELETE, CREATE,
DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES,
CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT,
CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER,
CREATE TABLESPACE ON *.* TO 'slave'@'202.187.194.255' WITH GRANT OPTIONIl semble que notre utilisateur esclave ait l'autorisation requise pour s'exécuter en tant qu'esclave (REPLICATION SLAVE).
Effectuer une sauvegarde mysqldump
Avant de créer une sauvegarde mysqldump externe, nous devons configurer les certificats SSL du client en raison du risque de connexion de l'instance via un réseau public. Pour cela, allez dans Connexions -> Configurer les certificats clients SSL -> Créer un certificat client :
Téléchargez les fichiers ci-dessus (server-ca.pem, client-cert. pem et client-key.pem) et stockez-les dans le serveur esclave. Nous allons utiliser ces certificats pour nous connecter en toute sécurité au maître depuis le serveur esclave. Pour simplifier le processus, tous les certificats ci-dessus et le fichier de clé seront placés dans un répertoire appelé "gcloud-certs":
$ mkdir -p /root/gcloud-certs # put the certs/key hereAssurez-vous que les autorisations sont correctes, en particulier le fichier de clé privée, client-key.pem :
$ chmod 600 /root/gcloud-certs/client-key.pemNous sommes maintenant prêts à effectuer une sauvegarde mysqldump de notre instance Google Cloud SQL MySQL 5.7 en toute sécurité :
$ mysqldump -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pem \
--single-transaction \
--all-databases \
--triggers \
--routines > fullbackup.sqlVous devriez recevoir l'avertissement suivant :
"Avertissement :Un vidage partiel d'un serveur qui a des GTID inclura par défaut les GTID de toutes les transactions, même celles qui ont modifié des parties supprimées de la base de données. Si vous ne voulez pas restaurer les GTID, passez --set-gtid-purged=OFF. Pour faire un dump complet, passez --all-databases --triggers --routines --events."
L'avertissement ci-dessus se produit parce que nous avons ignoré la définition de l'indicateur --events qui nécessite le privilège SUPER. L'utilisateur racine créé pour chaque instance Google Cloud SQL ne dispose pas des privilèges FILE et SUPER. C'est l'un des inconvénients de l'utilisation de cette méthode, à savoir que les événements MySQL ne peuvent pas être importés depuis Google Cloud SQL.
Configuration du serveur esclave
Sur le serveur esclave, installez MySQL 5.7 pour Debian 10 :
$ echo 'deb http://repo.mysql.com/apt/debian/ buster mysql-5.7' > /etc/apt/sources.list.d/mysql.list
$ apt-key adv --keyserver pgp.mit.edu --recv-keys 5072E1F5
$ apt update
$ apt -y install mysql-community-serverEnsuite, ajoutez les lignes suivantes sous la section [mysqld] dans /etc/mysql/my.cnf (ou tout autre fichier de configuration MySQL pertinent) :
server-id = 1111 # different value than the master
log_bin = binlog
log_slave_updates = 1
expire_logs_days = 7
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = 1
sync_binlog = 1
report_host = 202.187.194.255 # IP address of this slaveRedémarrez le serveur MySQL pour appliquer les modifications ci-dessus :
$ systemctl restart mysqlRestaurer la sauvegarde mysqldump sur ce serveur :
$ mysql -uroot -p < fullbackup.sqlÀ ce stade, le mot de passe racine MySQL du serveur esclave doit être identique à celui de Google Cloud SQL. Vous devez vous connecter avec un mot de passe root différent à partir de maintenant.
Notez que l'utilisateur racine dans Google Cloud ne dispose pas de tous les privilèges. Nous devons apporter quelques modifications du côté esclave, en permettant à l'utilisateur root d'avoir tous les privilèges à l'intérieur de MySQL, puisque nous avons plus de contrôle sur ce serveur. Pour ce faire, nous devons mettre à jour la table des utilisateurs de MySQL. Connectez-vous au serveur MySQL de l'esclave en tant qu'utilisateur root MySQL et exécutez l'instruction suivante :
mysql> UPDATE mysql.user SET Super_priv = 'Y', File_priv = 'Y' WHERE User = 'root';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0Videz la table des privilèges :
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)Quittez le terminal actuel et reconnectez-vous. Exécutez la commande suivante pour vérifier que l'utilisateur root dispose désormais du niveau de privilèges le plus élevé :
mysql> SHOW GRANTS FOR [email protected];
+---------------------------------------------------------------------+
| Grants for [email protected] |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+Configuration du lien de réplication
Pour des raisons de sécurité, l'utilisateur esclave de réplication doit se connecter à l'hôte maître (instance Google Cloud) via un canal crypté SSL. Par conséquent, nous devons préparer la clé et le certificat SSL avec les autorisations correctes et accessibles par l'utilisateur mysql. Copiez le répertoire gcloud dans /etc/mysql et attribuez l'autorisation et la propriété appropriées :
$ mkdir -p /etc/mysql
$ cp /root/gcloud-certs /etc/mysql
$ chown -Rf mysql:mysql /etc/mysql/gcloud-certsSur le serveur esclave, configurez le lien de réplication comme ci-dessous :
mysql> CHANGE MASTER TO MASTER_HOST = '35.198.197.171',
MASTER_USER = 'slave',
MASTER_PASSWORD = 'slavepassword',
MASTER_AUTO_POSITION = 1,
MASTER_SSL = 1,
MASTER_SSL_CERT = '/etc/mysql/gcloud-certs/client-cert.pem',
MASTER_SSL_CA = '/etc/mysql/gcloud-certs/server-ca.pem',
MASTER_SSL_KEY = '/etc/mysql/gcloud-certs/client-key.pem';Ensuite, démarrez l'esclave de réplication :
mysql> START SLAVE;Vérifiez la sortie comme suit :
mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 35.198.197.171
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 1120160
Relay_Log_File: puppet-master-relay-bin.000002
Relay_Log_Pos: 15900
Relay_Master_Log_File: mysql-bin.000003
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:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1120160
Relay_Log_Space: 16115
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/gcloud-certs/server-ca.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/gcloud-certs/client-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/gcloud-certs/client-key.pem
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: 2272712871
Master_UUID: 8539637e-14d1-11eb-ae3c-42010a94001a
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:5611-5664
Executed_Gtid_Set: 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664,
b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:Assurez-vous que les valeurs Slave_IO_Running et Slave_SQL_Running sont 'Oui', ainsi que Seconds_Behind_Master doit être 0, ce qui signifie que l'esclave a rattrapé le maître. Notez que l'Executed_Gtid_Set a deux GTID :
- 8539637e-14d1-11eb-ae3c-42010a94001a:1-5664
- b1dabe58-14e6-11eb-840f-0800278dc04d:1-2
Le premier GTID représente les modifications provenant du maître actuel (instance Google Cloud SQL), tandis que le second GTID représente les modifications que nous avons apportées lorsque nous avons modifié les privilèges de l'utilisateur racine MySQL sur l'hôte esclave. Faites attention au premier GTID pour voir si la base de données se réplique correctement (la partie entière doit être incrémentée lors de la réplication).
Vérifiez si notre hôte esclave fait partie de la réplication du point de vue du maître. Connectez-vous à l'instance SQL Cloud en tant qu'utilisateur root :
$ mysql -uroot -p \
-h 35.198.197.171 \
--ssl-ca=/root/gcloud-certs/server-ca.pem \
--ssl-cert=/root/gcloud-certs/client-cert.pem \
--ssl-key=/root/gcloud-certs/client-key.pemEt exécutez l'instruction suivante :
mysql> SHOW SLAVE HOSTS;
*************************** 1. row ***************************
Server_id: 1111
Host: 202.187.194.255
Port: 3306
Master_id: 2272712871
Slave_UUID: b1dabe58-14e6-11eb-840f-0800278dc04dÀ ce stade, vous pouvez planifier votre prochaine action pour rediriger la charge de travail de la base de données des applications vers ce serveur esclave en tant que nouveau serveur maître et désactiver l'ancien maître dans Google Cloud.
Réflexions finales
Vous pouvez effectuer une migration en ligne de Google Cloud SQL pour MySQL vers un serveur sur site sans trop de tracas. Cela vous donne la possibilité de déplacer votre base de données en dehors des fournisseurs de cloud pour plus de confidentialité et de contrôle lorsque le bon moment est venu.
