Limites et problèmes connus pour Amazon RDS for MySQL - Amazon Relational Database Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Limites et problèmes connus pour Amazon RDS for MySQL

Les limites et les problèmes connus liés à l'utilisation de Amazon RDS for MySQL sont répertoriés ci-dessous.

Mot réservé InnoDB

InnoDB est un mot réservé pour RDS for MySQL. Vous ne pouvez pas utiliser ce nom pour une base de données MySQL.

Comportement de stockage plein pour Amazon RDS for MySQL

Lorsque le stockage devient plein pour une instance de base de données MySQL, cela peut entraîner des incohérences de métadonnées, des incohérences de dictionnaire et des tables orphelines. Pour éviter ces problèmes, Amazon RDS arrête automatiquement une instance de base de données qui atteint l'état storage-full.

Une instance de base de données MySQL atteint l'état storage-full dans les cas suivants :

  • L'instance de base de données possède moins de 20 000 Mio de stockage et le stockage disponible atteint 200 Mio ou moins.

  • L'instance de base de données possède plus de 102 400 Mio de stockage et le stockage disponible atteint 1024 Mio ou moins.

  • L'instance de base de données possède entre 20 000 Mio et 102 400 Mio de stockage et dispose de moins de 1 % du stockage disponible.

Après l'arrêt automatique par Amazon RDS d'une instance de base de données car elle a atteint l'état storage-full, vous pouvez toujours la modifier. Pour redémarrer l'instance de base de données, effectuez au moins l'une des opérations suivantes :

Après avoir effectué l'une de ces modifications, l'instance de base de données est automatiquement redémarrée. Pour plus d'informations sur la modification d'une instance de base de données , consultez Modification d'une instance de base de données Amazon RDS.

Taille de pool de mémoires tampons InnoDB incohérente

Pour MySQL 5.7, il y a actuellement un bogue dans la manière dont la taille du pool de mémoires tampons InnoDB est gérée. MySQL 5.7 peut ajuster la valeur du paramètre innodb_buffer_pool_size sur une valeur importante qui peut entraîner un développement trop important du pool de mémoires tampons InnoDB et l'utilisation d'un trop gros volume de mémoire. Cet effet peut entraîner l'arrêt de l'exécution du moteur de base de données MySQL ou empêcher son démarrage. Ce problème est plus courant pour des classes d'instance de base de données dont l'espace mémoire disponible est moindre.

Pour résoudre ce problème, définissez la valeur du paramètre innodb_buffer_pool_size sur un multiple du produit des valeurs de paramètre innodb_buffer_pool_instances et innodb_buffer_pool_chunk_size. Par exemple, vous pouvez définir la valeur de paramètre innodb_buffer_pool_size sur un multiple de huit fois le produit des valeurs de paramètre innodb_buffer_pool_instances et innodb_buffer_pool_chunk_size, comme illustré dans l'exemple suivant.

innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

Pour plus d'informations sur ce bogue MySQL 5.7, consultez https://bugs.mysql.com/bug.php?id=79379 dans la documentation MySQL.

L'optimisation de la fusion d'index renvoie des résultats incorrects

Les requêtes qui utilisent l'optimisation de la fusion d'index peuvent renvoyer des résultats incorrects en raison d'un bogue dans l'optimiseur de requête MySQL introduit avec MySQL 5.5.37. Lorsque vous exécutez une requête sur une table avec plusieurs index, l'optimiseur analyse les plages de lignes selon les multiples index, mais il ne fusionne pas correctement les résultats. Pour plus d'informations sur le bogue de l'optimiseur de requête, consultez http://bugs.mysql.com/bug.php?id=72745 et http://bugs.mysql.com/bug.php?id=68194 dans la base de données des bogues MySQL.

Par exemple, imaginons une requête sur une table avec deux index où les arguments de la recherche font référence aux colonnes indexées.

SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

Dans ce cas, le moteur de recherche analysera les deux index. Néanmoins, en raison du bogue, les résultats fusionnés sont incorrects.

Pour résoudre ce problème, vous pouvez procéder de l'une des manières suivantes :

  • Définissez le paramètre optimizer_switch sur index_merge=off dans le groupe de paramètres DB de votre instance de base de données MySQL. Pour plus d'informations sur la définition des paramètres d'un groupe de paramètres DB, consultez Utilisation des groupes de paramètres.

  • Mettez à niveau votre instance de base de données MySQL vers MySQL version 5.7 ou 8.0. Pour plus d’informations, consultez Mise à niveau du moteur de base de données MySQL.

  • Si vous ne pouvez pas mettre à niveau votre instance ou modifier le paramètre optimizer_switch, vous pouvez contourner le bogue en identifiant explicitement un index pour la requête, par exemple :

    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

Pour en savoir plus, consultez Index merge optimization (Optimisation de la fusion d'index) dans la documentation MySQL.

Exceptions des paramètres MySQL pour les instances de base de données Amazon RDS

Certains paramètres MySQL nécessitent des considérations spéciales lors d'une utilisation avec une instance de base de données Amazon RDS.

lower_case_table_names

Comme Amazon RDS utilise un système de fichiers qui respecte la casse, la définition de la valeur du paramètre de serveur lower_case_table_names sur 2 (noms stockés tels qu'ils ont été fournis mais comparés en minuscules) n'est pas prise en charge. Voici les valeurs prises en charge pour les instances de base de données Amazon RDS for MySQL :

  • 0 (les noms stockés tels quels et les comparaisons sont sensibles à la casse) est pris en charge pour toutes les versions de RDS for MySQL.

  • 1 (les noms stockés en minuscules et les comparaisons ne sont pas sensibles à la casse) est pris en charge pour RDS for MySQL version 5.7 et version 8.0.28 et les versions 8.0 ultérieures.

Définissez le paramètre lower_case_table_names dans un groupe de paramètres de base de données personnalisé avant de créer une instance de base de données. Ensuite, spécifiez le groupe de paramètres de base de données personnalisé lorsque vous créez l'instance de base de données.

Quand un groupe de paramètres est associé à une instance de base de données MySQL dont la version est antérieure à la version 8.0, nous vous recommandons d'éviter de modifier le paramètre lower_case_table_names dans le groupe de paramètres. Sa modification peut entraîner des incohérences entre les sauvegardes de point-in-time restauration et la lecture des instances de base de données répliquées.

Quand un groupe de paramètres est associé à une instance de base de données MySQL version 8.0, vous ne pouvez pas modifier le paramètre lower_case_table_names dans le groupe de paramètres.

Les réplicas en lecture doivent toujours utiliser la même valeur de paramètre lower_case_table_names que l'instance de base de données source.

long_query_time

Vous pouvez définir le paramètre long_query_time sur une valeur à virgule flottante afin de pouvoir consigner les requêtes lentes dans le journal des requêtes lentes MySQL avec une résolution en microsecondes. Vous pouvez définir une valeur telle que 0,1 seconde, ce qui correspondrait à 100 millisecondes, pour aider lors du débogage de transactions lentes qui durent moins d'une seconde.

Limites de taille des fichiers MySQL dans Amazon RDS

Pour les instances de base de données MySQL, la limite maximale de stockage provisionnée limite la taille d'une table à une taille maximale de 16 To lors de l'utilisation des tablespaces InnoDB. file-per-table Cette limite restreint également l'espace de table du système à une taille maximum de 16 To. Les file-per-table tablespaces InnoDB (avec des tables chacune dans leur propre tablespace) sont définis par défaut pour les instances de base de données MySQL.

Note

Certaines instances de bases de données existantes ont une limite inférieure. Par exemple, les instances de base de données MySQL créées avant avril 2014 ont une limite de taille de fichier et de table de 2 To. Cette limite de taille de fichier de 2 To s'applique également aux instances de bases de données ou aux réplicas en lecture créés à partir d'instantanés de bases de données pris avant avril 2014, quel que soit le moment de la création de l'instance de base de données.

L'utilisation des file-per-table tablespaces InnoDB présente des avantages et des inconvénients, en fonction de votre application. Pour déterminer la meilleure approche pour votre application, consultez la section F ile-per-table tablespaces dans la documentation MySQL.

Il est déconseillé d'autoriser les tables à dépasser la taille maximale de fichier. En général, une meilleure pratique consiste à partitionner les données en tables plus petites, ce qui peut améliorer la performance et les temps de récupération.

Vous pouvez utiliser l'option de partitionnement pour diviser une grande table en tables plus petites. Le partitionnement répartit des portions de votre grande table en fichiers distincts basés sur des règles que vous spécifiez. Par exemple, si vous stockez des transactions par date, vous pouvez créer des règles de partitionnement qui répartissent des transactions plus anciennes en fichiers distincts en utilisant le partitionnement. Ensuite, vous pouvez archiver régulièrement les données de transaction historiques qui n'ont pas besoin d'être rapidement utilisables par votre application. Pour de plus amples informations, veuillez consulter Partitionnement dans la documentation MySQL.

Comme aucune table ou vue système ne fournit la taille de toutes les tables et de l'espace de table système InnoDB, vous devez interroger plusieurs tables pour déterminer la taille des espaces de table.

Pour déterminer la taille de l'espace de table système InnoDB et de l'espace de table du dictionnaire de données
  • Utilisez la commande SQL suivante pour déterminer si certains de vos espaces de table sont trop volumineux et pourraient faire l'objet d'un partitionnement.

    Note

    L'espace de table du dictionnaire de données est spécifique à MySQL 8.0.

    select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES where tablespace_name in ('mysql','innodb_system');
Pour déterminer la taille des tables utilisateur InnoDB en dehors de l'espace de table système InnoDB (pour les versions MySQL 5.7)
  • Utilisez la commande SQL suivante pour déterminer si certaines de vos tables sont trop volumineuses et peuvent faire l'objet d'un partitionnement.

    SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
Pour déterminer la taille des tables utilisateur InnoDB en dehors de l'espace de table système InnoDB (pour les versions MySQL 8.0)
  • Utilisez la commande SQL suivante pour déterminer si certaines de vos tables sont trop volumineuses et peuvent faire l'objet d'un partitionnement.

    SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" FROM information_schema.INNODB_TABLESPACES ORDER BY 3 DESC;
Pour déterminer la taille des tables utilisateur non-InnoDB
  • Utilisez la commande SQL suivante pour déterminer si certaines de vos tables utilisateur non-InnoDB sont trop volumineuses.

    SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE) / 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema') and ENGINE<>'InnoDB';
Pour activer les tablespaces InnoDB file-per-table
  • Définissez le paramètre innodb_file_per_table sur 1 dans le groupe de paramètres pour l'instance de base de données.

Pour désactiver les tablespaces InnoDB file-per-table
  • Définissez le paramètre innodb_file_per_table sur 0 dans le groupe de paramètres pour l'instance de base de données.

Pour plus d'informations sur la mise à jour d'un groupe de paramètres, consultez Utilisation des groupes de paramètres.

Lorsque vous avez activé ou désactivé les file-per-table tablespaces InnoDB, vous pouvez émettre une ALTER TABLE commande pour déplacer une table du tablespace global vers son propre tablespace, ou de son propre tablespace vers le tablespace global, comme indiqué dans l'exemple suivant :

ALTER TABLE table_name ENGINE=InnoDB;

Plug-in MySQL Keyring non pris en charge

Actuellement, Amazon RDS for MySQL ne prend pas en charge le plug-in MySQL keyring_aws Amazon Web Services Keyring.

Ports personnalisés

Amazon RDS bloque les connexions au port personnalisé 33060 pour le moteur MySQL. Choisissez un port différent pour votre moteur MySQL.

Limitations des procédures stockées MySQL

Les procédures stockées mysql.rds_kill et mysql.rds_kill_query ne peuvent pas mettre fin à des sessions ou à des requêtes appartenant à des utilisateurs MySQL dont le nom d'utilisateur comporte plus de 16 caractères sur les versions suivantes de RDS for MySQL :

  • 8.0.32 et versions 8 antérieures

  • 5.7.41 et versions 5.7 antérieures

Réplication basée sur GTID avec une instance source externe

Amazon RDS ne prend pas en charge la réplication basée sur les identifiants de transaction globaux (GTID) à partir d'une instance MySQL externe vers une instance de base de données Amazon RDS for MySQL qui requiert la définition de GTID_PURGED au cours de la configuration.

Plugin d'authentification par défaut MySQL

RDS pour MySQL version 8.0.34 et supérieure utilise le plugin. mysql_native_password Vous ne pouvez pas modifier le paramètre default_authentication_plugin.