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

Limites et problèmes connus pour MySQL sur Amazon RDS

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

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 le démarrage du moteur de base de données MySQL. 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 le bogue MySQL 5.7, consultez https://bugs.mysql.com/bug.php?id=79379 dans la documentation MySQL.

L'optimisation de la fusion d'index retourne des résultats erronés

Les requêtes qui utilisent d'optimisation de fusionnement d'index peuvent produire des résultats fautifs en raison d'un bogue dans l'optimiseur de requête MySQL introduit avec MySQL 5.5.37. Lorsque vous publiez une requête contre un tableau avec plusieurs index, l'optimiseur analyse des plages de rangées 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, accédez à 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 de groupes de paramètres de base de données.

  • Mettez à niveau votre instance de base de données vers MySQL version 5.6, 5.7 ou 8.0. Pour plus d'informations, consultez Mise à niveau d'un instantané 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 de plus amples informations, veuillez consulter Optimisation de la fusion d'index.

Taille des fichiers journaux

Pour MySQL, une taille limite est appliquée aux objets BLOB écrits dans le fichier journal redo. Pour prendre en compte cette limite, vérifiez que le paramètre innodb_log_file_size de votre instance de base de données MySQL est dix fois supérieur à la taille des données BLOB les plus volumineuses figurant dans vos tables, plus la longueur des autres champs de longueur variable (VARCHAR, VARBINARY, TEXT) dans ces tables. Pour plus d'informations sur la manière de définir les valeurs des paramètres, consultez Utilisation de groupes de paramètres de base de données. Pour plus d'informations sur la taille limite des objets BLOB du fichier journal redo, accédez à Changements dans MySQL 5.6.20.

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

Du fait que Amazon RDS utilise un système de fichiers qui respecte la casse, la définition de la valeur du paramètre du serveur lower_case_table_names sur 2 (« noms stockés comme donnés 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 pour MySQL :

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

  • 1 (« les noms stockés en minuscules et les comparaisons ne sont pas sensibles à la casse ») est pris en charge pour Amazon RDS pour les version 5.5, 5.6, 5.7 et 8.0.19 et 8.0 ultérieures de MySQL.

Le paramètre lower_case_table_names doit être défini dans le cadre d'un groupe de paramètres DB personnalisé avant de créer une instance de base de données. Vous devez éviter de changer le paramètre lower_case_table_names pour les instances de base de données existantes, car cela pourrait entraîner des incohérences avec les sauvegardes de restauration à un instant dans le passé et les instances de base de données de réplica en lecture.

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 qui vous permet de consigner des requêtes lentes dans le journal des requêtes lentes MySQL avec une résolution en 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.

Limites de taille des fichiers MySQL dans Amazon RDS

Pour les instances de base de données Amazon RDS MySQL, la limite maximale de stockage alloué restreint la taille d'une table à un maximum de 16 To lors de l'utilisation des espaces de table file-per-table InnoDB. Cette limite restreint également l'espace de table du système à une taille maximum de 16 To. Les espaces de table file-per-table InnoDB (avec des tables chacun dans leur propre espace de table) sont définis par défaut pour les instances de base de données Amazon RDS 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.

Selon votre application, l'utilisation des espaces de table file-per-table InnoDB présente des avantages et des inconvénients. Pour déterminer l'approche optimale pour votre application, veuillez consulter File-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.

Une option que vous pouvez utiliser pour diviser une grande table en plus petites consiste à partitionner. 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.

Pour déterminer la taille de fichier d'une table

  • 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 TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

Pour activer les espaces de table file-per-table InnoDB

  • Pour activer les tablespaces file-per-table d'InnoDB, affectez au paramètre innodb_file_per_table la valeur 1 dans le groupe de paramètres relatif à l'instance de base de données.

Pour désactiver les espaces de table file-per-table InnoDB

  • Pour désactiver les tablespaces file-per-table d'InnoDB, affectez au paramètre innodb_file_per_table la valeur 0 dans le groupe de paramètres relatif à l'instance de base de données.

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

Après avoir activé ou désactivé les espaces de table file-per-table InnoDB, vous pouvez émettre une commande ALTER TABLE pour déplacer une table à partir de l'espace de table global vers son propre espace de table, ou à partir de son propre espace de table vers l'espace de table global, comme illustré dans l'exemple suivant :

ALTER TABLE table_name ENGINE=InnoDB;

Plug-in MySQL Keyring non pris en charge

Pour l'instant, Amazon RDS pour MySQL ne prend pas en charge le plug-in MySQL keyring_aws Amazon Web Services Keyring.