Points importants à prendre en compte avant la migration d'Aurora vers Cloud SQL pour MySQL
La plate-forme AWS d'Amazon et Google Cloud fournissent tous deux des services de base de données MySQL entièrement gérés dans le cloud. Ces deux fournisseurs de services cloud ont des caractéristiques propres et présentent des différences dans leurs configurations par défaut. Ces différences peuvent entraîner des problèmes de performances ou opérationnels inattendus après une migration de l'un des fournisseurs vers l'autre. Cet article présente un résumé des problèmes pouvant survenir lors d'une telle migration, ainsi que les solutions recommandées. L'article s'intéresse plus particulièrement aux migrations de services de base de données MySQL depuis Aurora MySQL vers Cloud SQL pour MySQL.
Considérations sur la migration
Jeu de caractères : problème de performances
Aurora utilise latin1 comme jeu de caractères par défaut (jusqu'à la version MySQL 5.7). Cela diffère de la configuration par défaut de Cloud SQL pour MySQL pour les bases de données, les tables, les procédures stockées et les fonctions, qui sont créées avec utf8 comme jeu de caractères par défaut lors d'une migration.Cela peut entraîner des problèmes de performances.
Par exemple, un utilisateur peut se retrouver dans une situation où des tables sont créées avec le jeu de caractères latin1 et que des procédures ou des fonctions stockées sont créées avec le jeu de caractères par défaut de Cloud SQL, utf8. Dans de tels cas, si la procédure ou la fonction stockée attend une variable en tant que paramètre utf8 et la compare à la valeur de la colonne (qui a comme jeu de caractères latin1), cela entraînera des problèmes de performances en raison de la comparaison et des classements à gérer dans deux jeux de caractères différents.
Vous pouvez vérifier le jeu de caractères des routines à l'aide de la commande ci-dessous :
|
mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES; |
Si vous utilisiez le jeu de caractères par défaut d'Aurora (jusqu'à la version 5.7), c'est-à-dire latin1, vous devez passer le jeu de caractères par défaut d'utf8 à latin1 dans Cloud SQL avant d'importer les données.
Une autre solution consisterait à tout passer en utf8. Toutefois, dans ce cas, les utilisateurs doivent tester l'intégralité de l'application et de l'ensemble de données, car les modifications apportées au jeu de caractères peuvent entraîner des représentations de données inattendues.
Les utilisateurs peuvent modifier ce paramètre au niveau de l'instance Cloud SQL dans la section "Options", comme illustré ci-dessous.
Jeu de caractères : problème d'incompatibilité
Aurora MySQL 5.7 présente de nombreux classements (par exemple, utf8mb4_0900_ai_ci pour le jeu de caractères utf8mb4), qui ne sont actuellement disponibles que dans dans la version 8.0 de Cloud SQL pour MySQL. Si vous utilisez l'un de ces classements et que vous importez les données dans Cloud SQL pour MySQL en version 5.7, vous obtiendrez un message d'erreur du type "Error 'Character set '#255' is not a compiled character set" (Erreur : le jeu de caractères "#255" n'est pas un jeu de caractères compilé).
La solution consiste à remplacer ces classements par des classements disponibles dans MySQL version 5.7.
Moteur de stockage : toutes les tables doivent se trouver dans InnoDB
Contrairement à Aurora, Cloud SQL pour MySQL n'est pas compatible avec le moteur MyISAM. Il est conseillé de convertir toutes les tables en InnoDB avant de démarrer la migration d'Aurora vers Cloud SQL.
S'il existe une table dans un moteur autre qu'InnoDB, les utilisateurs peuvent modifier le moteur de la table à l'aide de la commande "ALTER" :
|
mysql> alter table table_1 engine='Innodb' ; Query OK, 0 rows affected (2.89 sec) Records: 0 Duplicates: 0 Warnings: 0 |
Remarque : La durée de cette requête dépend de la taille de la table et peut bloquer d'autres opérations sur cette table. Vous pouvez également utiliser des outils de modification de schéma en ligne comme pt-online-schema-change ou gh-ost afin de modifier la table sans bloquer d'autres opérations.
Points de terminaison pour les connexions en lecture
Dans Aurora, les utilisateurs peuvent configurer plusieurs lecteurs derrière un même point de terminaison. Toutefois, cette fonctionnalité n'est pas disponible de manière prête à l'emploi pour les utilisateurs de Cloud SQL pour MySQL. Chaque instance dupliquée avec accès en lecture de Cloud SQL pour MySQL possède sa propre adresse IP. Les utilisateurs doivent donc utiliser un outil tel que ProxySQL pour répartir le trafic entre plusieurs instances dupliquées avec accès en lecture.
Aurora ne possède pas de tampon de modification
Le tampon de modification est une structure de données spéciale qui met en cache les modifications apportées aux pages d'index secondaires lorsque ces pages ne figurent pas dans le pool de mémoire tampon, et effectue ultérieurement la fusion des modifications lorsque ces pages sont chargées dans le pool de mémoire tampon par d'autres opérations de lecture. Pour en savoir plus, consultez la section Tampon de modification.
Dans un cas d'utilisation où la charge de travail comporte beaucoup d'écritures sur des tables avec des index secondaires, Aurora peut être plus lent que Cloud SQL pour MySQL, qui utilise la fonctionnalité de tampon de modification InnoDB par défaut pour reporter ces mises à jour à un stade ultérieur. Les utilisateurs doivent effectuer une analyse comparative des performances basée sur leur charge de travail d'application.
Le cache de requêtes peut avoir un impact sur les performances
Le cache de requêtes stocke la commande "SELECT" ainsi que son résultat dans une couche de stockage intermédiaire. Si une instruction identique est reçue ultérieurement, le serveur vérifie le cache de requêtes et y récupère les résultats au lieu d'exécuter à nouveau cette commande. Le cache de requêtes étant partagé entre les sessions, toutes les sessions peuvent bénéficier des résultats mis en cache par les instructions déjà exécutées dans d'autres sessions. En savoir plus sur le cache de requêtes.
Aurora active le cache de requêtes par défaut. Toutefois, la communauté MySQL a désactivé le cache de requêtes dans la version 5.7 et l'a complètement supprimé dans la version 8.0. Cloud SQL pour MySQL a fait de même. Si vos requêtes reposent sur la fonctionnalité de cache de requêtes d'Aurora, les performances peuvent varier dans Cloud SQL pour MySQL. Il est recommandé de tester les performances de vos requêtes dans Cloud SQL pour MySQL en comparant leur durée d'exécution avec celle dans Aurora.
Le mécanisme de réplication peut avoir un impact sur les performances
Pour les instances dupliquées avec accès en lecture au sein d'une région, Aurora utilise le concept de volume de cluster, qui contient des copies des données dans trois zones de disponibilité de cette région. Le délai de réplication dans Aurora est généralement très inférieur à 100 millisecondes, car l'instance principale et les instances dupliquées du même cluster de base de données voient toutes les données figurant dans le volume de cluster comme un seul volume logique. En outre, pour les instances dupliquées avec accès en lecture interrégionales, Aurora utilise la synchronisation de données sur disque entre les régions au lieu de la réplication basée sur les journaux binaires.
En bref, la réplication est gérée par la couche de stockage dans Aurora, tandis que dans Cloud SQL pour MySQL, le mécanisme de réplication standard consiste à transférer le journal binaire vers les instances dupliquées, puis à utiliser la relecture de ce journal dans les instances MySQL dupliquées. Les performances de la réplication peuvent être améliorées en configurant la réplication parallèle dans Cloud SQL. Consultez les détails sur la configuration de la réplication parallèle.
Bien que le délai de réplication dépende de la quantité de données modifiées par l'application et du réseau entre l'instance principale et l'instance dupliquée, la plupart des applications fonctionnent sans délai notable dans Aurora et Cloud SQL pour MySQL Toutefois, si l'application est intensive en écriture et qu'elle effectue des lectures à partir des instances dupliquées, nous vous suggérons d'effectuer une analyse comparative du délai de réplication dans AWS Aurora et Cloud SQL pour MySQL avant la migration.
Réplication basée sur l'identifiant de transaction global (GTID)
Contrairement à AWS Aurora, Cloud SQL pour MySQL utilise une réplication GTID qui utilise la synchronisation des données sur disque. Avant de migrer, les utilisateurs doivent vérifier les limites de la réplication GTID répertoriées ci-dessous et apporter les modifications nécessaires dans leur application si son workflow dépend de l'une de ces fonctionnalités :
- Les instructions "CREATE TABLE ... SELECT" ne sont pas autorisées lors de l'utilisation de la réplication basée sur GTID.
- Les instructions "CREATE TEMPORARY TABLE" et "DROP TEMPORARY TABLE" ne sont pas acceptées dans les transactions, les procédures, les fonctions ni les déclencheurs. Il est possible d'utiliser ces instructions lorsque les GTID sont activés, mais uniquement en dehors de toute transaction, et uniquement avec "autocommit=1".
Pour en savoir plus sur les limites associées aux GTID, consultez la sections Limites avec GTID.
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.
