Il existe plusieurs façons de migrer vers MySQL sur Cloud SQL. La stratégie de migration d'une source donnée dépend de plusieurs facteurs, y compris de la taille de la base de données, des temps d'arrêt attendus et de l'expérience des ingénieurs effectuant la migration. Examinons quelques-unes des stratégies de migration les plus courantes.

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.

Pour migrer de nombreuses instances de MySQL ou pour 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.

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.

MySQL est unique parmi les systèmes de bases de données relationnelles les plus populaires dans la mesure où il prend en charge plusieurs moteurs de stockage connectables. À l'origine, MySQL n'acceptait qu'un seul moteur de stockage appelé MyISAM. Jusqu'à MySQL 8.0, la plupart des tables système utilisaient ce moteur. Cependant, MyISAM n'était pas compatible avec les transactions et n'était pas 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 permet 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 CREATE 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.

MySQL pour Cloud SQL étant un service géré, il n'autorise pas les droits SUPER pour les comptes utilisateur. Il s'agit d'une différence par rapport à la plupart des installations sur site de MySQL qui autorisent un utilisateur racine disposant d'un tel privilège. De même, la plupart des autres fournisseurs de services cloud ne fournissent pas ce privilège SUPER dans un environnement MySQL géré.

Quelle que soit la situation dans Cloud SQL, les utilisateurs reçoivent un utilisateur 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 et SHUTDOWN. 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 d'examiner l'ensemble actuel de droits et de déterminer si certains sont restreints dans Cloud SQL. De même, l'outil pt-show-grants de Percona peut également répertorier les autorisations.

Les restrictions sur les privilèges utilisateur dans Cloud SQL peuvent affecter les migrations lors de la migration d'objets de base de données comportant un attribut DEFINER. C'est souvent le cas des procédures stockées, des déclencheurs, des fonctions définies par l'utilisateur et des vues. Si le 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.

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 différer d'une installation à l'autre, et entraîner des différences de stockage et de performances Par exemple, latin1 ou 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. Par exemple, il est possible de redimensionner le pool de mémoire tampon InnoDB en modifiant innodb_buffer_pool_size. Toutefois, certains paramètres InnoDB plus précis ne peuvent pas être modifiés dans Cloud SQL ou avoir des valeurs par défaut différentes de celles sur site ou d'autres fournisseurs cloud.