Points importants à prendre en compte avant la migration d'Aurora vers Cloud SQL pour MySQL

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.

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.

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.

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 répliqué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 répliquées avec accès en lecture.

Ce guide décrit comment utiliser ProxySQL pour acheminer le trafic entre plusieurs instances dupliquées avec accès en lecture.

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 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.

Pour les instances répliqué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 répliqué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 répliqué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 répliquées, puis à utiliser la relecture de ce journal dans les instances MySQL répliqué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 répliqué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 répliqué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.

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 section Limites avec GTID.