Bonnes pratiques pour la migration vers Cloud SQL pour MySQL
La planification et l'exécution d'une migration de bases de données de MySQL vers Cloud SQL pour MySQL impliquent de nombreux facteurs, notamment la complexité de la base de données à migrer, la quantité de données à migrer et le niveau de temps d'arrêt pouvant être toléré. L'un de ces facteurs est l'instance source de la base de données MySQL. L'instance source de MySQL peut être hébergée de l'une des manières suivantes :
- Instance MySQL hébergée sur un autre fournisseur de services cloud tel qu'AWS ou Azure
- Instance MySQL hébergée dans votre propre centre de données ou depuis un serveur de votre bureau (méthode appelée "sur site")
Cet article s'applique à ces deux scénarios.
Articles associés
Présentation
Il existe deux principaux types de migrations de bases de données. Les migrations depuis une instance source exécutant MySQL ou une base de données dotée d'un serveur d'interface comme MySQL (par exemple, AWS Aurora pour MySQL) vers MySQL dans le cloud ou Cloud SQL pour MySQL sont considérées comme des migrations homogènes. Dans les cas où l'instance source exécute une base de données différente telle que PostgreSQL, SQL Server, Oracle ou toute base de données autre que la destination, ce type de migration est appelé "migrations hétérogènes".
Cet article met l'accent sur les migrations homogènes, comme c'est généralement le cas avec Cloud SQL pour MySQL. Il présente en particulier les différentes manières de migrer vers Cloud SQL pour MySQL, les points à prendre en compte quant aux moteurs de stockage, les droits d'utilisateur et les options MySQL. Toutefois, de nombreux conseils et pratiques peuvent également s'appliquer aux migrations hétérogènes.
Méthodes de migration vers Cloud SQL pour MySQL
Il existe différentes manières de migrer vers MySQL sur Cloud SQL. La stratégie de migration d'une source donnée dépend de plusieurs facteurs, tels que la taille de la base de données, les temps d'arrêt attendus et l'expérience des ingénieurs qui effectuent la migration. Examinons certaines des stratégies de migration les plus courantes.
Importation Cloud Storage
Si vous migrez sur une petite base de données de quelques gigaoctets ou contenant des données statiques, l'approche la plus simple consiste à effectuer un dump de la base de données via l'utilitaire mysqldump. Importez le fichier de vidage dans Cloud Storage, puis importez-le dans une instance Cloud SQL en suivant les instructions de l'article Exporter et importer des données à l'aide de fichiers de dump SQL.
Étant donné que les fichiers de dump contiennent des instructions SQL logiques, l'un des avantages de cette approche est qu'il est possible de les modifier avant de les charger dans Cloud Storage. Toutefois, certaines restrictions Cloud SQL évitent d'inclure dans le fichier de dump des éléments susceptibles d'interrompre une importation, comme indiqué dans les bonnes pratiques pour l'importation et l'exportation de données.
Database Migration Service (DMS)
Pour migrer de nombreuses instances de MySQL ou des migrations plus importantes, il est préférable d'utiliser le service Database Migration Service (DMS). Ce service offre divers chemins de migration, y compris des chemins pour les migrations homogènes et hétérogènes vers MySQL, ainsi que la compatibilité avec SQL Server et PostgreSQL en tant que destinations de migration.
Pour la plupart des migrations de bases de données de moyenne à grande taille, le recours au service DMS devrait suffire. Le service DMS peut ne pas être approprié dans certains situations, notamment avec les bases de données très volumineuses (de plusieurs To) ou si vous disposez d'ingénieurs MySQL ayant de l'expérience en réplication et qui préfèrent un contrôle plus précis du processus de migration à l'aide de la réplication MySQL native.
Réplication de la source externe
Si la limitation des temps d'arrêt est une priorité pendant la migration et que vous disposez d'ingénieurs MySQL expérimentés dans votre équipe, il est possible d'effectuer une réplication à partir d'une source externe (ES) à l'aide de la réplication native basée sur les journaux binaires. Cette solution utilise l'importation d'un instantané de référence de votre base de données à l'aide d'une méthode telle qu'une importation Cloud Storage.
Vous allez ensuite configurer la réplication MySQL de l'instance source vers l'instance Cloud SQL cible à l'aide d'un ensemble de procédures stockées prédéfinies qui sont disponibles sur l'instance Cloud SQL. Vous trouverez des instructions complètes dans l'article Utiliser une importation personnalisée pour configurer la réplication à partir de bases de données externes volumineuses.
Notez bien que lorsque vous utilisez la réplication basée sur les journaux binaires pour la migration, les journaux binaires de l'instance source restent disponibles jusqu'à ce que l'instance Cloud SQL cible n'en ait plus besoin. Lorsque vous exécutez MySQL sur site ou en mode autogéré, vous pouvez configurer des paramètres tels que expire_logs_days pour contrôler la suppression définitive des journaux binaires. Toutefois, d'autres services gérés par les fournisseurs de services cloud possèdent leur propre restriction sur la conservation des journaux binaires.
Par exemple, Amazon Relational Database Service (RDS) permet de configurer la conservation des journaux binaires via un nom de procédure stockée mysql.rds_set_configuration. Cela permet de les conserver jusqu'à sept jours. Dans la plupart des cas, sept jours sont suffisants pour la plupart des migrations de petite à moyenne taille de RDS à Cloud SQL. Dans de tels cas, les utilisateurs peuvent exploiter un processus bien documenté impliquant la création d'une instance répliquée RDS gérée. Effectuez ensuite une action pour "briser" la réplication, par exemple rendre l'instance répliquée accessible en écriture et supprimer une ligne, ou injecter une forme de transaction "poison" sur l'instance principale qui s'introduit dans le journal binaire et interrompt la réplication. L'automatisation de RDS ne supprime pas définitivement les journaux binaires tant que l'instance répliquée en a besoin (bien qu'il semble exister une limite globale de 30 jours avant que RDS "arrête" un flux de réplication interrompu).
Une autre solution consiste à utiliser le client mysqlbinlog pour télécharger les journaux binaires sur une autre instance MySQL intermédiaire afin d'empêcher la suppression définitive prématurée des journaux binaires. Par exemple, dans RDS, il existe une procédure stockée nommée mysql.rds_set_configuration qui permet de définir une durée de conservation en heures pour garantir que les journaux binaires restent suffisamment longtemps sur l'hôte pour le téléchargement. Dans ce cas, vous n'avez pas besoin de mettre en place une instance MySQL en tant qu'intermédiaire, car tout serveur (par exemple, un serveur Binlog) ressemblant à une instance MySQL est là pour stocker et transférer les journaux binaires.
Remarques concernant les moteurs de stockage
Parmi les systèmes de base de données relationnelle les plus populaires, MySQL est unique car compatible avec plusieurs moteurs de stockage connectables. À l'origine, MySQL était compatible avec un seul moteur de stockage appelé MyISAM et, jusqu'à MySQL 8.0, la plupart des tables système utilisaient ce moteur de stockage. Toutefois, MyISAM n'était pas compatible avec les transactions et n'était pas parfaitement sécurisé en cas d'arrêt soudain du système ou de plantage de la base de données.
Depuis, InnoDB est devenu le moteur de stockage de facto pour la plupart des tables d'utilisateurs MySQL, compte tenu de son architecture sécurisée en cas de plantage et de sa compatibilité avec les transactions. Il existe d'autres moteurs de stockage couramment utilisés dans la communauté MySQL, à la fois sur site et chez d'autres fournisseurs de services cloud, parmi lesquels :
- ARCHIVE : stocke les données sous un format hautement compressé à des fins d'archivage
- CSV : stocke les données sous un format CSV (valeurs séparées par des virgules) et permet de consigner les tables du journal de requêtes général et lent
- MEMORY : stocke les tables en mémoire
Cloud SQL nécessite, quant à lui, un moteur de stockage transactionnel et sécurisé en cas de plantage pour les fonctionnalités à valeur ajoutée, telles que la réplication et la récupération à un moment précis. Par conséquent, toutes les tables d'utilisateur migrant vers Cloud SQL doivent utiliser le moteur de stockage InnoDB ou être converties en InnoDB pendant le processus de migration.
Cela est particulièrement important si vous effectuez une réplication MySQL native à partir d'une source externe vers Cloud SQL. Bien que Cloud SQL ne permette pas aux utilisateurs de créer une table MyISAM directement sur une instance Cloud SQL via des commandes LDD (langage de définition de données), telles que CRÉER UNE TABLE, il est actuellement possible de répliquer des tables MyISAM à partir d'une source externe vers Cloud SQL.
Toutefois, ces tables MyISAM importées sur Cloud SQL peuvent entraîner plus tard des problèmes de stabilité et de fiabilité au cours d'opérations telles que la réplication, la récupération à un moment précis et le basculement. Pour cette raison, il est conseillé de convertir toutes les tables d'utilisateur MyISAM en InnoDB avant d'effectuer la migration.
La requête suivante répertorie toutes les tables MyISAM hors système.
Droits d'utilisateur
En tant que service géré, MySQL pour Cloud SQL n'autorise pas le droit SUPER pour les comptes utilisateur. Il s'agit d'un changement majeur par rapport à la plupart des installations sur site de MySQL qui permettent à un utilisateur racine de disposer d'un tel droit. De même, la plupart des autres fournisseurs de services cloud ne proposent pas ce droit SUPER dans un environnement MySQL géré.
Quelle que soit la situation dans Cloud SQL, les utilisateurs reçoivent unutilisateur MySQL par défaut nommé "root'@'%" qui accorde à la plupart des utilisateurs des droits fournis par MySQL, à l'exception de ceux susceptibles d'affecter la capacité de Google à gérer le service, telles que les droits SUPER (susmentionné), FILE etSHUTDOWN. Pour en savoir plus sur les droits d'utilisateur fournis dans Cloud SQL, consultez la documentation sur les utilisateurs MySQL.
Lorsque vous préparez la migration, examinez tous les comptes utilisateur de l'instance source. Par exemple, exécutez la commande SHOW GRANTS pour chaque utilisateur afin de passer en revue l'ensemble de droits actuels et de vérifier s'ils sont restreints dans Cloud SQL. De même, l'outil pt-show-grants de Percona permet également de répertorier les attributions de droits.
Les restrictions sur les droits d'utilisateur dans Cloud SQL peuvent affecter les migrations lors de la migration d'objets de base de données disposant d'un attribut DEFINER. C'est souvent le cas pour les procédures stockées, les déclencheurs, les fonctions définies par l'utilisateur et les vues. Si la définition d'un objet de base de données sur l'instance source est un utilisateur disposant d'un droit non compatible avec Cloud SQL, cela peut poser un problème pendant ou après la migration.
Par exemple, une procédure stockée peut comporter une définition de droit super permettant d'exécuter des commandes SQL, comme la modification d'une variable globale non autorisée dans Cloud SQL. Dans de tels cas, il peut être nécessaire de réécrire le code de la procédure stockée ou de migrer des objets hors table tels que des procédures stockées lors d'une étape de migration distincte.
Notre documentation comporte une section intitulée Tâches d'importation et de migration MySQL contenant des métadonnées avec la clause DEFINER, qui traite un peu plus en détails des autres problèmes liés à la clause de définition des objets de base de données.
Options
En raison des restrictions de droits d'utilisateur mentionnées précédemment, les utilisateurs ne peuvent pas appeler de manière native la commande SET GLOBAL pour modifier les paramètres de la base de données. À la place, Cloud SQL propose un ensemble prédéfini d'"options" que vous pouvez modifier via la console d'interface utilisateur, la GCloud CLI et l'API REST afin de modifier les paramètres.
La liste complète des options Cloud SQL pour MySQL est disponible dans la documentation publique, dans la section Options compatibles. Avant de migrer vers Cloud SQL, comparez la liste des options compatibles et celle des options actuellement utilisées dans votre environnement source. Par exemple, une bonne pratique consiste à créer une instance Cloud SQL de test avec des paramètres de processeur et de mémoire similaires à ceux de votre instance source, puis à exécuter SHOW GLOBAL VARIABLES sur l'instance source et l'instance Cloud SQL, puis comparez les différences.
Les options courantes qui peuvent comporter des paramètres différents sur site ou chez un fournisseur de services cloud par rapport à Cloud SQL pour MySQL sont les suivantes :
- Paramètres du jeu de caractères et du classement, tels que character_set_server et collation_server. Les valeurs par défaut peuvent varier d'une installation à l'autre et entraîner des différences de stockage et de performances. Par exemple, latin1 et utf8.
- Paramètres du journal binaire, tels que binlog_format. Actuellement, Cloud SQL n'accepte que la journalisation basée sur les lignes dans le journal binaire.
- Paramètres de réplication avancés. Par exemple, Cloud SQL n'est pas compatible avec les paramètres de filtre de réplication tels que replicate-do-table et replicate-do-db
- Paramètres InnoDB avancés. Cloud SQL permet de modifier la plupart des paramètres liés à InnoDB, tels que le redimensionnement du pool de mémoire tampon InnoDB en modifiant innodb_buffer_pool_size. Toutefois, il se peut que d'autres paramètres InnoDB plus précis ne soient pas modifiables dans Cloud SQL ou soient associés à des valeurs par défaut différentes de celles présentes sur site ou chez d'autres fournisseurs de services cloud.
Produits et services associés
Google Cloud propose une base de données MySQL gérée conçue pour répondre aux besoins de votre entreprise, de la suppression de votre centre de données sur site à l'exécution d'applications SaaS, en passant par la migration de systèmes d'entreprise principaux.
