Problèmes connus et limites d'Amazon RDS for My SQL - Amazon Relational Database Service
Mot réservé InnoDBComportement de stockage pleinTaille de pool de mémoires tampons InnoDB incohérenteL'optimisation de la fusion d'index renvoie des résultats incorrectsMes exceptions de SQL paramètres pour les RDS instances de base de données AmazonMes limites de taille de SQL fichier sur Amazon RDSLe plugin My SQL Keyring n'est pas pris en chargePorts personnalisésLimites de mes procédures SQL stockéesGTIDréplication basée sur une instance source externeMon plugin d'authentification SQL par défautRemplacer innodb_buffer_pool_size

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.

Problèmes connus et limites d'Amazon RDS for My SQL

Les problèmes et limites connus liés à l'utilisation d'Amazon RDS for My SQL sont les suivants.

Mot réservé InnoDB

InnoDBest un mot réservé à RDS for MySQL. Vous ne pouvez pas utiliser ce nom pour une base de SQL données Ma base de données.

Comportement d'Amazon RDS for My en cas de saturation du stockage SQL

Lorsque le stockage d'une instance My SQL DB est saturé, il peut y avoir des incohérences dans les métadonnées, des incohérences dans les dictionnaires et des tables orphelines. Pour éviter ces problèmes, Amazon arrête RDS automatiquement une instance de base de données qui atteint storage-full cet état.

Une instance My SQL DB atteint l'storage-fullétat 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.

Une fois qu'Amazon RDS arrête automatiquement une instance de base de données parce qu'elle a atteint son storage-full état, 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 RDS instance de base de données Amazon.

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

Pour My SQL 5.7, il existe actuellement un bogue dans la façon dont la taille du pool de tampons InnoDB est gérée. Mon SQL 5.7 peut ajuster la valeur du innodb_buffer_pool_size paramètre à une valeur élevée, ce qui peut entraîner une trop grande taille du pool de tampons InnoDB et une utilisation excessive de mémoire. Cet effet peut entraîner l'arrêt du moteur Ma SQL base de données ou l'empêcher de démarrer. 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 de détails sur ce bogue de My SQL 5.7, consultez le https://bugs.mysql.comfichier /bug.php ? id=79379 dans la section Ma documentation. SQL

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 SQL requêtes My SQL 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êtes, consultez http://bugs.mysql.com/bug.php?id=72745 et http://bugs.mysql.com/bug.php?id=68194 dans la base de données My SQL bug.

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 optimizer_switch paramètre sur index_merge=off dans le groupe de paramètres de base de données de votre instance My SQL DB. Pour plus d'informations sur la définition des paramètres d'un groupe de paramètres DB, consultez Groupes de paramètres pour Amazon RDS.

  • Mettez à niveau votre instance My SQL DB vers My SQL version 5.7 ou 8.0. Pour de plus amples informations, veuillez consulter Mises à niveau du moteur RDS for My SQL DB.

  • 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 plus d'informations, consultez la section Optimisation de la fusion d'index dans la section Ma SQL documentation.

Mes exceptions de SQL paramètres pour les RDS instances de base de données Amazon

Certains SQL paramètres My nécessitent des considérations particulières lorsqu'ils sont utilisés avec une RDS instance de base de données Amazon.

lower_case_table_names

Amazon RDS utilisant un système de fichiers sensible aux majuscules et minuscules, il n'est pas possible de définir la valeur lower_case_table_names du paramètre du serveur sur 2 (noms stockés tels quels mais comparés en minuscules). Les valeurs prises en charge pour les instances Amazon RDS for My SQL DB sont les suivantes :

  • 0 (les noms sont stockés tels quels et les comparaisons distinguent les majuscules et minuscules) est pris en charge RDS pour toutes les SQL versions de My.

  • 1 (les noms sont stockés en minuscules et les comparaisons ne font pas la distinction entre majuscules et minuscules) est pris en charge RDS pour My SQL version 5.7 et versions 8.0.28 et versions 8.0 supé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.

Lorsqu'un groupe de paramètres est associé à une instance My SQL DB dont la version est inférieure à 8.0, nous vous recommandons d'éviter de modifier le lower_case_table_names paramètre 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.

Lorsqu'un groupe de paramètres est associé à une instance My SQL DB version 8.0, vous ne pouvez pas modifier le lower_case_table_names paramètre 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 long_query_time paramètre sur une valeur à virgule flottante afin de pouvoir enregistrer les requêtes lentes dans le journal My SQL slow query log avec une résolution de l'ordre de la microseconde. 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.

Mes limites de taille de SQL fichier sur Amazon RDS

Pour les instances My SQL DB, la limite de stockage maximale allouée limite la taille d'une table à 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 My DB. SQL

Note

Certaines instances de bases de données existantes ont une limite inférieure. Par exemple, les instances My SQL DB 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 section Ma SQL documentation.

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 plus d'informations, consultez la section Partitionnement dans la section Ma SQL documentation.

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 SQL commande suivante pour déterminer si certains de vos espaces disque logiques sont trop grands et sont susceptibles d'être partitionnés.

    Note

    Le tablespace du dictionnaire de données est spécifique à My SQL 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 du système InnoDB (pour les versions My 5.7) SQL

  • Utilisez la SQL commande suivante pour déterminer si l'une de vos tables est trop grande et peut être partitionnée.

    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 du système InnoDB (pour les versions My 8.0) SQL

  • Utilisez la SQL commande suivante pour déterminer si l'une de vos tables est trop grande et peut être partitionnée.

    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 SQL commande suivante pour déterminer si l'une de vos tables d'utilisateurs autres que celles d'InnoDB est trop grande.

    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 Groupes de paramètres pour Amazon RDS.

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 TABLESPACE=innodb_file_per_table;

Le plugin My SQL Keyring n'est pas pris en charge

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

Ports personnalisés

Amazon RDS bloque les connexions au port personnalisé 33060 pour le SQL moteur My. Choisissez un autre port pour votre SQL moteur My Engine.

Limites de mes procédures SQL stockées

Les mysql.rds_kill procédures mysql.rds_kill_query stockées ne peuvent pas mettre fin aux sessions ou aux requêtes détenues par Mes SQL utilisateurs dont le nom d'utilisateur comporte plus de 16 caractères, comme suit RDS pour Mes SQL versions :

  • 8.0.32 et versions 8 antérieures

  • 5.7.41 et versions 5.7 antérieures

GTIDréplication basée sur une instance source externe

Amazon RDS prend en charge la réplication basée sur des identifiants de transaction globaux (GTIDs) depuis une SQL instance externe My vers une instance Amazon RDS for My SQL DB qui nécessite de définir GTID _ PURGED lors de la configuration. Toutefois, seules RDS les versions SQL 8.0.37 et supérieures de My prennent en charge cette fonctionnalité.

Mon plugin d'authentification SQL par défaut

RDSpour My SQL version 8.0.34 et supérieure, utilisez le mysql_native_password plugin. Vous ne pouvez pas modifier le paramètre default_authentication_plugin.

Remplacer innodb_buffer_pool_size

Dans le cas de classes d'instance de base de données de petite ou de petite taille, la valeur par défaut du innodb_buffer_pool_size paramètre peut être différente de la valeur renvoyée en exécutant la commande suivante : 

mysql> SELECT @@innodb_buffer_pool_size;

Cette différence peut se produire lorsqu'Amazon RDS doit remplacer la valeur par défaut dans le cadre de la gestion des classes d'instances de base de données. Si nécessaire, vous pouvez remplacer la valeur par défaut et la définir sur une valeur prise en charge par votre classe d'instance de base de données. Pour déterminer une valeur valide, ajoutez l'utilisation de la mémoire et la mémoire totale disponible sur votre instance de base de données. Pour plus d'informations, consultez la section Types d'RDSinstances Amazon.

Si votre instance de base de données ne dispose que de 4 Go de mémoire, vous ne pouvez pas la innodb_buffer_pool_size définir sur 8 Go, mais vous pouvez peut-être la définir sur 3 Go, en fonction de la quantité de mémoire que vous avez allouée aux autres paramètres.

Si la valeur que vous saisissez est trop élevée, Amazon la RDS réduit aux limites suivantes :

  • Classes d'instances Micro DB : 256 Mo

  • Classes d'instance de base de données db.t4g.micro : 128 Mo