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. # Tâches DBA courantes pour les instances de base de données MySQL Vous trouverez dans le contenu ci-après une description, pour des implémentations spécifiques à Amazon RDS, de certaines tâches d’administrateur de base de données courantes pour les instances de base de données RDS exécutant le moteur de base de données Oracle. Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de base de données. Il restreint également l’accès à certaines procédures système et tables qui requièrent des privilèges avancés. Pour plus d’informations sur l’utilisation des fichiers journaux MySQL sur Amazon RDS, consultez [Fichiers journaux de base de données MySQL](USER_LogAccess.Concepts.MySQL.md). ## Présentation des utilisateurs prédéfinis Amazon RDS crée automatiquement plusieurs utilisateurs prédéfinis avec les nouvelles instances de base de données RDS for MySQL. Les utilisateurs prédéfinis et leurs privilèges ne peuvent pas être modifiés. Vous ne pouvez pas supprimer, renommer ou modifier les privilèges de ces utilisateurs prédéfinis. Toute tentative de ce type génère une erreur. + **rdsadmin** : utilisateur créé pour gérer la plupart des tâches de gestion que l’administrateur qui utilise les privilèges `superuser` aurait exécutées sur une base de données MySQL autonome. Cet utilisateur est utilisé en interne par RDS for MySQL pour de nombreuses tâches de gestion. + **rdsrepladmin** : utilisateur utilisé en interne par Amazon RDS pour prendre en charge les activités de réplication sur les instances et clusters de bases de données RDS for MySQL. Pour en savoir plus sur les autres tâches DBA courantes, consultez les rubriques suivantes. **Topics** + [Présentation des utilisateurs prédéfinis](#Appendix.MySQL.CommonDBATasks.users) + [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md) + [Privilèges dynamiques pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.dynamic-privileges.md) + [Mettre fin à une session ou à une requête pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.End.md) + [Ignorer une erreur de réplication pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md) + [Utilisation des espaces de table InnoDB pour améliorer les temps de récupération sur incident pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.Tables.md) + [Gestion de l’historique global des statuts de RDS for MySQL](Appendix.MySQL.CommonDBATasks.GoSH.md) + [Configuration de la taille du groupe de mémoires tampons et de la capacité du journal de reprise dans MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md) # Modèle de privilège basé sur les rôles pour RDS for MySQL À compter de RDS for MySQL version 8.0.36, vous ne pouvez pas modifier les tables dans la base de données `mysql` directement. En particulier, vous ne pouvez pas créer d’utilisateurs de base de données en effectuant des opérations du langage de manipulation des données (DML) sur les tables `grant`. Vous utilisez plutôt des instructions de gestion de compte MySQL telles que `CREATE USER`, `GRANT`, et `REVOKE` pour accorder des privilèges basés sur les rôles aux utilisateurs. Vous ne pouvez pas non plus créer d'autres types d'objets tels que des procédures stockées dans la base de données `mysql`. Vous pouvez toujours interroger les tables `mysql`. Si vous utilisez la réplication des journaux binaires, les modifications apportées directement aux tables `mysql` de l’instance de base de données source ne sont pas répliquées sur le cluster cible. Dans certains cas, votre application peut utiliser des raccourcis pour créer des utilisateurs ou d'autres objets en les insérant dans les tables `mysql`. Le cas échéant, modifiez le code de votre application pour utiliser les instructions correspondantes telles que `CREATE USER`. Pour exporter des métadonnées pour les utilisateurs de bases de données pendant la migration à partir d’une base de données MySQL externe, utilisez une des méthodes suivantes : + Utilisez l’utilitaire de vidage d’instance de MySQL Shell avec un filtre pour exclure les utilisateurs, les rôles et les autorisations. L’exemple suivant illustre la syntaxe de commande à utiliser. Vérifiez que `outputUrl` est vide. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Pour plus d’informations, consultez les sections [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) dans le manuel de référence MySQL. + Utilisez l’utilitaire client `mysqlpump`. Cet exemple inclut toutes les tables à l’exception des tables de la base de données système `mysql`. Elle comprend également les instructions `CREATE USER` et `GRANT` pour reproduire tous les utilisateurs MySQL de la base de données migrée. ``` mysqlpump --exclude-databases=mysql --users ``` L’utilitaire client `mysqlpump` n’est plus disponible avec MySQL 8.4. Utilisez à la place `mysqldump`. Pour simplifier la gestion des autorisations pour de nombreux utilisateurs ou applications, vous pouvez utiliser l'instruction `CREATE ROLE` pour créer un rôle doté d'un ensemble d'autorisations. Vous pouvez ensuite utiliser les instructions `GRANT` et `SET ROLE`, et la fonction `current_role` pour attribuer des rôles à des utilisateurs ou des applications, changer le rôle actuel et vérifier les rôles en vigueur. Pour plus d'informations sur le système d'autorisations basé sur les rôles dans MySQL 8.0, consultez [Utilisation de rôles](https://dev.mysql.com/doc/refman/8.0/en/roles.html) dans le manuel de référence MySQL. **Important** Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application. À compter de la version 8.0.36, RDS for MySQL inclut un rôle spécial doté de tous les privilèges suivants. Ce rôle est nommé `rds_superuser_role`. Ce rôle est déjà accordé à l’utilisateur administratif principal de chaque instance de base de données. Le rôle `rds_superuser_role` inclut les privilèges suivants pour tous les objets de base de données : + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` La définition du rôle inclut également `WITH GRANT OPTION` afin qu'un utilisateur administratif puisse accorder ce rôle à d'autres utilisateurs. En particulier, l’administrateur doit accorder tous les privilèges nécessaires à la réplication des journaux binaires avec le cluster MySQL comme cible. **Astuce** Pour voir tous les détails des autorisations, utilisez l’instruction suivante. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Lorsque vous accordez l’accès à l’aide de rôles dans RDS for MySQL versions 8.0.36 et ultérieures, vous activez également le rôle à l’aide de l’instruction `SET ROLE role_name` ou `SET ROLE ALL`. L’exemple suivant montre comment procéder. Remplacez le nom de rôle approprié par `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ``` # Privilèges dynamiques pour RDS for MySQL Les privilèges dynamiques sont des privilèges MySQL que vous pouvez explicitement accorder à l’aide de l’instruction `GRANT`. Selon votre version de RDS for MySQL, RDS vous permet de n’accorder que des privilèges dynamiques spécifiques. RDS refuse certains de ces privilèges, car ils peuvent interférer avec des opérations de base de données spécifiques, telles que la réplication et la sauvegarde. Le tableau suivant indique quels privilèges vous pouvez accorder pour les différentes versions de MySQL. Si vous effectuez une mise à niveau d’une version de MySQL inférieure à 8.0.36 vers une version 8.0.36 ou supérieure, vous devrez peut-être mettre à jour le code de votre application si l’octroi d’un privilège particulier n’est plus autorisé. | Privilège | MySQL 8.0.35 et versions inférieures | MySQL 8.0.36 et versions mineures ultérieures | MySQL 8.4.3 et versions ultérieures | | --- | --- | --- | --- | | [ALLOW\$1NONEXISTENT\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_allow-nonexistent-definer) | Non disponible | Non disponible | Non autorisé | | [APPLICATION\$1PASSWORD\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_application-password-admin) | Autorisé | Autorisé | Autorisé | | [AUDIT\$1ABORT\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-abort-exempt) | Autorisé | Non autorisé | Non autorisé | | [AUDIT\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-admin) | Non autorisé | Non autorisé | Non autorisé | | [AUTHENTIFICATION\$1POLICY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_authentication-policy-admin) | Autorisé | Non autorisé | Non autorisé | | [BACKUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin) | Autorisé | Non autorisé | Non autorisé | | [BINLOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-admin) | Autorisé | Non autorisé | Non autorisé | | [BINLOG\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-encryption-admin) | Non autorisé | Non autorisé | Non autorisé | | [CLONE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_clone-admin) | Non autorisé | Non autorisé | Non autorisé | | [CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_connection-admin) | Autorisé | Non autorisé | Non autorisé | | [ENCRYPTION\$1KEY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_encryption-key-admin) | Non autorisé | Non autorisé | Non autorisé | | [FIREWALL\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-admin) | Non autorisé | Non autorisé | Non autorisé | | [FIREWALL\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-exempt) | Autorisé | Non autorisé | Non autorisé | | [FIREWALL\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-user) | Non autorisé | Non autorisé | Non autorisé | | [FLUSH\$1OPTIMIZER\$1COSTS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-optimizer-costs) | Autorisé | Autorisé | Autorisé | | [FLUSH\$1PRIVILEGES](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_flush-privileges) | Non disponible | Non disponible | Autorisé | | [FLUSH\$1STATUS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-status) | Autorisé | Autorisé | Autorisé | | [FLUSH\$1TABLES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-tables) | Autorisé | Autorisé | Autorisé | | [FLUSH\$1USER\$1RESOURCES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-user-resources) | Autorisé | Autorisé | Autorisé | | [GROUP\$1REPLICATION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-admin) | Non autorisé | Non autorisé | Non autorisé | | [GROUP\$1REPLICATION\$1STREAM](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-stream) | Non autorisé | Non autorisé | Non autorisé | | [INNODB\$1REDO\$1LOG\$1ARCHIVE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-archive) | Non autorisé | Non autorisé | Non autorisé | | [INNODB\$1REDO\$1LOG\$1ENABLE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-enable) | Non autorisé | Non autorisé | Non autorisé | | [MASKING\$1DICTIONARIES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_masking-dictionaries-admin) | Non autorisé | Non autorisé | Non autorisé | | [NDB\$1STORED\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_ndb-stored-user) | Non autorisé | Non autorisé | Non autorisé | | [OPTIMIZE\$1LOCAL\$1TABLE](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_optimize-local-table) | Non disponible | Non disponible | Non autorisé | | [PASSWORDLESS\$1USER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_passwordless-user-admin) | Non autorisé | Non autorisé | Non autorisé | | [PERSIST\$1RO\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_persist-ro-variables-admin) | Non autorisé | Non autorisé | Non autorisé | | [REPLICATION\$1APPLIER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-applier) | Autorisé | Non autorisé | Non autorisé | | [REPLICATION\$1SLAVE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave-admin) | Non autorisé | Non autorisé | Non autorisé | | [RESOURCE\$1GROUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) | Autorisé | Non autorisé | Non autorisé | | [RESOURCE\$1GROUP\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) | Autorisé | Non autorisé | Non autorisé | | [ROLE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_role-admin) | Autorisé | Autorisé | Autorisé | | [SENSITIVE\$1VARIABLES\$1OBSERVER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_sensitive-variables-observer) | Autorisé | Autorisé | Autorisé | | [SERVICE\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_service-connection-admin) | Autorisé | Non autorisé | Non autorisé | | [SESSION\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_session-variables-admin) | Autorisé | Autorisé | Autorisé | | [SET\$1ANY\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_set-any-definer) | Non disponible | Non disponible | Autorisé | | [SET\$1USER\$1ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id) | Autorisé | Autorisé | Non disponible | | [SHOW\$1ROUTINE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_show-routine) | Autorisé | Autorisé | Autorisé | | [SKIP\$1QUERY\$1REWRITE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_skip-query-rewrite) | Non autorisé | Non autorisé | Non autorisé | | [SYSTEM\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-user) | Non autorisé | Non autorisé | Non autorisé | | [SYSTEM\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-variables-admin) | Non autorisé | Non autorisé | Non autorisé | | [TABLE\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_table-encryption-admin) | Non autorisé | Non autorisé | Non autorisé | | [TELEMETRY\$1LOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_telemetry-log-admin) | Autorisé | Non autorisé | Non autorisé | | [TP\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_tp-connection-admin) | Non autorisé | Non autorisé | Non autorisé | | [TRANSACTION\$1GTID\$1TAG](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_transaction-gtid-tag) | Non disponible | Non disponible | Non autorisé | | [VERSION\$1TOKEN\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_version-token-admin) | Non autorisé | Non autorisé | Non autorisé | | [XA\$1RECOVER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_xa-recover-admin) | Autorisé | Autorisé | Autorisé | # Mettre fin à une session ou à une requête pour RDS for MySQL Vous pouvez mettre fin aux sessions d'utilisateur ou requêtes sur les instances de base de données à l'aide des commandes `rds_kill` et `rds_kill_query`. Connectez-vous d'abord à votre instance de base de données MySQL, puis émettez la commande appropriée comme illustré ci-après. Pour plus d’informations, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md). ``` CALL mysql.rds_kill(thread-ID) CALL mysql.rds_kill_query(thread-ID) ``` Par exemple, pour arrêter la session qui s'exécute sur le thread 99, entrez la commande suivante : ``` CALL mysql.rds_kill(99); ``` Pour arrêter la requête qui s'exécute sur le thread 99, entrez la commande suivante : ``` CALL mysql.rds_kill_query(99); ``` # Ignorer une erreur de réplication pour RDS for MySQL Amazon RDS fournit un mécanisme qui vous permet d'ignorer une erreur sur vos réplicas en lecture, si l'erreur entraîne une absence de réponse du réplica en lecture et qu'elle n'affecte pas l'intégrité de vos données. **Note** D'abord, vérifiez que l'erreur concernée peut être ignorée en toute sécurité. Dans un utilitaire MySQL, connectez-vous au réplica en lecture et exécutez la commande MySQL suivante. ``` SHOW REPLICA STATUS\G ``` Pour plus d’informations sur les valeurs renvoyées, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Les versions précédentes de MySQL utilisaient`SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version MySQL antérieure à la version 8.0.23, utilisez `SHOW SLAVE STATUS`. Vous pouvez ignorer une erreur sur votre réplica en lecture de la manière suivante. **Topics** + [Appel de la procédure mysql.rds\$1skip\$1repl\$1error](#Appendix.MySQL.CommonDBATasks.SkipError.procedure) + [Définition du paramètre slave\$1skip\$1errors](#Appendix.MySQL.CommonDBATasks.SkipError.parameter) ## Appel de la procédure mysql.rds\$1skip\$1repl\$1error Amazon RDS fournit une procédure stockée que vous pouvez appeler pour ignorer une erreur sur vos réplicas en lecture. Connectez-vous d'abord à votre réplica en lecture, puis émettez les commandes appropriées comme illustré ci-après. Pour plus d’informations, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md). Pour ignorer l'erreur, émettez la commande suivante. ``` CALL mysql.rds_skip_repl_error; ``` Cette commande n'a aucun effet si vous l'exécutez sur l'instance de base de données source ou sur un réplica en lecture qui n'a rencontré aucune erreur de réplication. Pour plus d'informations, telles que les versions de MySQL qui prennent en charge `mysql.rds_skip_repl_error`, consultez [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). **Important** Si vous essayez d'appeler `mysql.rds_skip_repl_error` et que vous rencontrez l'erreur suivante : `ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist`, mettez à niveau votre instance de base de données MySQL avec la dernière version mineure ou avec l'une des versions mineures minimales répertoriées dans [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). ## Définition du paramètre slave\$1skip\$1errors Pour ignorer une ou plusieurs erreurs, vous pouvez définir le paramètre statique `slave_skip_errors` sur le réplica en lecture. Vous pouvez définir ce paramètre pour ignorer un ou plusieurs codes d'erreur de réplication spécifiques. Actuellement, vous pouvez définir ce paramètre uniquement pour les instances de base de données RDS for MySQL 5.7. Après avoir modifié ce paramètre, veillez à redémarrer votre instance de base de données pour que le nouveau paramètre prenne effet. Pour plus d'informations sur le fonctionnement de ces paramètres, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors) : Nous vous recommandons de définir ce paramètre dans un groupe de paramètres de base de données distinct. Vous pouvez associer ce groupe de paramètres de base de données aux réplicas en lecture qui doivent ignorer les erreurs. Le suivi de cette bonne pratique réduit l'impact potentiel sur d'autres instances de base de données et réplicas en lecture. **Important** La définition d'une valeur autre que par défaut pour ce paramètre peut entraîner une incohérence de la réplication. Ne définissez ce paramètre sur une valeur autre que par défaut que si vous avez épuisé d'autres options pour résoudre le problème et que vous êtes sûr de l'impact potentiel sur les données de votre réplica en lecture. # Utilisation des espaces de table InnoDB pour améliorer les temps de récupération sur incident pour RDS for MySQL Chaque table de MySQL se compose d'une définition de table, de données et d'index. Le moteur de stockage MySQL InnoDB stocke les données de table et les index dans un *tablespace*. InnoDB crée un espace de table global partagé qui contient un dictionnaire de données et autres métadonnées pertinentes, et peut contenir des données de table et des index. InnoDB peut aussi créer des espaces de table distincts pour chaque table et partition. Ces espaces de table distincts sont stockés dans des fichiers ayant .ibd comme extension et l'en-tête de chaque espace de table contient un numéro qui l'identifie de façon unique. Amazon RDS fournit un paramètre dans un groupe de paramètres MySQL appelé `innodb_file_per_table`. Ce paramètre contrôle le fait qu'InnoDB ajoute ou non de nouvelles données et de nouveaux index de tables au tablespace partagé (en définissant la valeur du paramètre du 0) ou à des tablespaces individuels (en définissant la valeur du paramètre sur 1). Amazon RDS définit la valeur par défaut pour le paramètre `innodb_file_per_table` sur 1, ce qui vous permet d'abandonner des tables InnoDB individuelles afin de libérer l'espace de stockage que ces tables utilisent au profit de l'instance de base de données. Dans la plupart des cas d'utilisation, la définition du paramètre `innodb_file_per_table` à la valeur 1 est celle recommandée. Vous devez définir le paramètre `innodb_file_per_table` à la valeur 0 quand vous avez un nombre important de tables, tel que plus de 1 000 tables quand vous utilisez le stockage SSD standard (magnétique) ou à visée générale, ou plus de 10 000 tables quand vous utilisez le stockage IOPS provisionnées. Lorsque vous définissez ce paramètre à la valeur 0, les espaces de table individuels ne sont pas créés et cela peut améliorer le temps nécessaire pour la récupération sur incident de base de données. MySQL traite chaque fichier de métadonnées, espaces de tables inclus, pendant le cycle de récupération sur incident. Le temps nécessaire à MySQL pour traiter les informations de métadonnées dans l'espace de table partagé est négligeable en comparaison du temps qu'il faut pour traiter des milliers de fichiers d'espace de table quand il y a plusieurs espaces de table. Comme le nombre d'espaces de table est stocké au sein de l'en-tête de chaque fichier, le temps total nécessaire pour lire tous les fichiers d'espace de table peut prendre jusqu'à plusieurs heures. Par exemple, un million d'espaces de table InnoDB sur un stockage standard peut nécessiter entre cinq et huit heures de traitement pendant un cycle de récupération sur incident. Dans certains, InnoDB peut déterminer qu'il a besoin d'un nettoyage supplémentaire après un cycle de récupération sur incident et, par conséquent, entamera un autre cycle de récupération sur incident, ce qui augmente le temps total de récupération. Gardez à l'esprit qu'un cycle de récupération sur incident implique aussi la restauration de transactions, la correction des pages rompues et autres opérations en plus du traitement des informations sur les espaces de table. Comme le paramètre `innodb_file_per_table` réside dans un groupe de paramètres, vous pouvez modifier la valeur du paramètre en modifiant le groupe de paramètres utilisé par votre instance de base de données sans avoir à redémarrer celle-ci. Une fois que la valeur est modifiée, de la valeur 1 (créer des tables individuelles) à la valeur 0 (utiliser un espace de table partagé), par exemple, les nouvelles tables InnoDB sont ajoutées à l'espace de table partagé, pendant que les tables existantes continuent d'avoir des espaces de table individuels. Pour déplacer une table InnoDB vers l'espace de table partagé, vous devez utiliser la commande `ALTER TABLE`. ## Migration de plusieurs espaces de table vers l'espace de table partagé Vous pouvez déplacer les métadonnées d'une table InnoDB de son propre espace de table vers l'espace de table partagé, ce qui recrée les métadonnées de la table selon la valeur du paramètre `innodb_file_per_table`. Connectez-vous d'abord à votre instance de base de données MySQL, puis émettez les commandes appropriées comme illustré ci-après. Pour plus d’informations, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md). ``` ALTER TABLE table_name ENGINE = InnoDB, ALGORITHM=COPY; ``` Par exemple, la requête suivante retourne une instruction `ALTER TABLE` pour chaque table InnoDB qui ne figure pas dans l'espace de table partagé. **Pour les instances de base de données MySQL 5.7 :** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` **Pour les instances de base de données MySQL 8.4 et 8.0 :** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` La reconstruction d'une table MySQL pour déplacer les métadonnées de la table vers l'espace de table partagé nécessite temporairement un espace de stockage supplémentaire pour recréer la table et, par conséquent, l'instance de base de données doit avoir un espace de stockage disponible. Pendant la reconstruction, la table est verrouillée et inaccessible aux requêtes. Pour les petites tables ou les tables qui ne sont pas fréquemment consultées, ce n'est pas nécessairement un problème. Pour les tables volumineuses ou fréquemment consultées dans un environnement fortement concurrentiel, vous pouvez reconstruire les tables sur un réplica en lecture. Vous pouvez créer un réplica en lecture et migrer les métadonnées de la table vers l'espace de table partagé du réplica en lecture. Tant que l'instruction ALTER TABLE bloque l'accès sur le réplica en lecture, l'instance de base de données source n'est pas impactée. L'instance de base de données source continue à générer ses journaux binaires, tandis que le réplica en lecture ralentit pendant le processus de reconstruction de la table. Étant donné que la reconstruction exige un espace de stockage supplémentaire et que le fichier journal de relecture peut devenir volumineux, vous devriez créer un réplica en lecture dont la capacité de stockage allouée est supérieure à l'instance de base de données source. Pour créer un réplica en lecture et reconstruire les tables InnoDB afin d'utiliser l'espace de table partagé, procédez comme suit : 1. Assurez-vous que la rétention des sauvegardes est activée sur l'instance de base de données source de sorte que la journalisation binaire soit activée. 1. Utilisez le AWS Management Console ou AWS CLI pour créer une réplique en lecture pour l'instance de base de données source. Étant donné que la création d'un réplica en lecture implique un grand nombre de processus semblables à ceux de la récupération sur incident, le processus de création peut prendre un certain temps si le nombre d'espaces de table InnoDB est élevé. Allouez plus d'espace de stockage sur le réplica en lecture qu'il n'en est actuellement utilisé sur l'instance de base de données source. 1. Lorsque le réplica en lecture a été créé, créez un groupe de paramètres avec les valeurs de paramètre `read_only = 0` et `innodb_file_per_table = 0`. Associez ensuite le groupe de paramètres au réplica en lecture. 1. Émettez l'instruction SQL suivante pour toutes les tables que vous souhaitez migrer sur le réplica : ``` ALTER TABLE name ENGINE = InnoDB ``` 1. Une fois que toutes vos instructions `ALTER TABLE` sont terminées sur le réplica en lecture, vérifiez que celui-ci est connecté à l'instance de base de données source et que les deux instances sont synchronisées. 1. Utilisez la console ou l'interface de ligne de commande (CLI) pour promouvoir le réplica en lecture comme instance. Assurez-vous que le groupe de paramètres utilisé pour la nouvelle instance de base de données autonome a le paramètre `innodb_file_per_table` défini sur 0. Modifiez le nom de la nouvelle instance de base de données autonome et pointez toutes les applications vers la nouvelle instance de base de données autonome. # Gestion de l’historique global des statuts de RDS for MySQL **Astuce** Pour analyser les performances des bases de données, vous pouvez également utiliser l'analyse des performances sur Amazon RDS. Pour plus d’informations, consultez [Surveillance de la charge de la base de données avec Performance Insights sur Amazon RDS](USER_PerfInsights.md). MySQL gère de nombreuses variables d’état qui fournissent des informations sur son fonctionnement. Leur valeur peut vous aider à détecter les problèmes de verrouillage ou de mémoire d'une instance de base de données. Les valeurs de ces variables d’état se cumulent depuis le dernier démarrage de l’instance de base de données. Vous pouvez réinitialiser à la valeur 0 la plupart des variables d’état à l’aide de la commande `FLUSH STATUS`. Pour autoriser la surveillance de ces valeurs au fil du temps, Amazon RDS fournit un ensemble de procédures qui prennent un instantané des valeurs de ces variables et les écrivent dans une table, ainsi que toutes les modifications intervenues depuis le dernier instantané. Cette infrastructure, appelée historique global des statuts (GoSH, Global Status History), est installée sur toutes les instances de base de données MySQL à partir des versions 5.5.23. GoSH est désactivé par défaut. Pour activer GoSH, vous devez d'abord activer le planificateur d'événement à partir d'un groupe de paramètres de base de données en définissant le paramètre `event_scheduler` sur `ON`. Pour les instances de base de données MySQL exécutant MySQL 5.7, définissez également le paramètre `show_compatibility_56` sur `1`. Pour plus d’informations sur la création et la modification d’un groupe de paramètres DB, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md). Pour obtenir des informations sur les effets secondaires de l'activation de ce paramètre, consultez [show\$1compatibility\$156](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_show_compatibility_56) dans le *Manuel de référence de MySQL 5.7*. Vous pouvez ensuite utiliser les procédures du tableau suivant pour activer et configurer GoSH. Connectez-vous d'abord à votre instance de base de données MySQL, puis émettez les commandes appropriées comme illustré ci-après. Pour de plus amples informations, veuillez consulter [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md). Pour chaque procédure, exécutez la commande suivante et remplacez **procedure-name**: ``` CALL procedure-name; ``` Le tableau suivant répertorie toutes les procédures que vous pouvez utiliser **procedure-name**dans la commande précédente. | Procédure | Description | | --- | --- | | `mysql.rds_enable_gsh_collector` | Active l'infrastructure GoSH pour prendre des instantanés par défaut à intervalles spécifiés par `rds_set_gsh_collector`. | | `mysql.rds_set_gsh_collector` | Spécifie l'intervalle, en minutes, entre les instantanés. La valeur par défaut est 5. | | `mysql.rds_disable_gsh_collector` | Désactive les instantanés. | | `mysql.rds_collect_global_status_history` | Prend un instantané sur demande. | | `mysql.rds_enable_gsh_rotation` | Active la rotation du contenu de la table `mysql.rds_global_status_history` en `mysql.rds_global_status_history_old` à intervalles spécifiés par `rds_set_gsh_rotation`. | | `mysql.rds_set_gsh_rotation` | Spécifie l'intervalle, en jours, entre deux rotations de table. La valeur par défaut est 7. | | `mysql.rds_disable_gsh_rotation` | Désactive la rotation de table. | | `mysql.rds_rotate_global_status_history` | Effectue une rotation du contenu de la table `mysql.rds_global_status_history` en `mysql.rds_global_status_history_old` à la demande. | Lorsque l'infrastructure GoSH est en cours d'exécution, vous pouvez interroger les tables sur lesquelles elle écrit. Par exemple, pour interroger le taux d'accès du groupe de tampons Innodb, vous devez émettre la requête suivante : ``` select a.collection_end, a.collection_start, (( a.variable_Delta-b.variable_delta)/a.variable_delta)*100 as "HitRatio" from mysql.rds_global_status_history as a join mysql.rds_global_status_history as b on a.collection_end = b.collection_end where a. variable_name = 'Innodb_buffer_pool_read_requests' and b.variable_name = 'Innodb_buffer_pool_reads' ``` # Configuration de la taille du groupe de mémoires tampons et de la capacité du journal de reprise dans MySQL 8.4 Dans MySQL 8.4, Amazon RDS active le paramètre `innodb_dedicated_server` par défaut. Avec le paramètre `innodb_dedicated_server`, le moteur de base de données calcule les paramètres `innodb_buffer_pool_size` et `innodb_redo_log_capacity`. Pour en savoir plus sur la façon dont ces paramètres sont calculés, consultez [Configuration de la taille du groupe de mémoires tampons InnoDB](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html) et [Journal de rétablissement](https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html) dans la documentation MySQL. Lorsque `innodb_dedicated_server` est activé, le paramètre `innodb_buffer_pool_size` est calculé en fonction de la mémoire de la classe d’instance de base de données. Le tableau suivant affiche la mémoire de serveur détectée et la taille du groupe de mémoires tampons correspondant. | Mémoire de serveur détectée | Taille du groupe de mémoires tampons | | --- | --- | | < 1 Go | Valeur par défaut de 128 Mo | | 1 Go à 4 Go | *Detected server memory*\$1 0,5 | | > 4 Go | *Detected server memory*\$1 0,75 | Le `innodb_redo_log_capacity` paramètre évolue automatiquement avec la classe d'instance jusqu'à (nombre de vCPUs /2) Go jusqu'à un maximum de 16 Go. Les classes d’instance plus importantes ont une capacité de journal de rétablissement, ce qui peut améliorer les performances et la résilience pour les charges de travail intensives en écriture. Avant de passer de MySQL 8.0 à MySQL 8.4, assurez-vous d’augmenter votre espace de stockage pour faire face à une éventuelle augmentation de la taille des journaux de rétablissement qui pourrait survenir une fois la mise à niveau terminée. Pour plus d’informations, consultez [Augmentation de la capacité de stockage d'une instance de base de données](USER_PIOPS.ModifyingExisting.md). Si vous ne souhaitez pas que le paramètre `innodb_dedicated_server` calcule les valeurs des paramètres `innodb_redo_log_capacity` et `innodb_buffer_pool_size`, vous pouvez remplacer ces valeurs en leur attribuant des valeurs spécifiques dans un groupe de paramètres personnalisés. Vous pouvez également désactiver le paramètre `innodb_dedicated_server` et définir des valeurs pour les paramètres `innodb_redo_log_capacity` et `innodb_buffer_pool_size` dans un groupe de paramètres personnalisés. Pour plus d’informations, consultez [Groupes de paramètres par défaut et personnalisés](parameter-groups-overview.md#parameter-groups-overview.custom). Si vous désactivez le paramètre `innodb_dedicated_server` en le définissant sur `0` et ne définissez pas de valeurs pour les paramètres `innodb_redo_log_capacity` et `innodb_buffer_pool_size`, Amazon RDS définit les deux derniers paramètres sur 128 Mo et 100 Mo, respectivement. Ces valeurs par défaut se traduisent par des performances médiocres sur des classes d’instance plus importantes.