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.
# Amazon RDS for MySQL
Amazon RDS prend en charge plusieurs versions de MySQL pour les instances de base de données. Pour des informations complètes sur les versions prises en charge, consultez [Versions de MySQL sur Amazon RDS](MySQL.Concepts.VersionMgmt.md).
Pour créer une instance de base de données Amazon RDS for MySQL, utilisez les outils de gestion ou les interfaces Amazon RDS. Vous pouvez alors effectuer ce qui suit :
+ Redimensionner votre instance de base de données
+ Autorisation des connexions à votre instance de base de données
+ Créer et restaurer à partir de sauvegardes ou d'instantanés
+ Créer des secondaires Multi-AZ
+ Créer des réplicas en lecture
+ Surveiller les performances de votre instance de base de données
Pour stocker les données de votre instance de base de données et y accéder, utilisez les applications et les utilitaires MySQL standard.
Amazon RDS for MySQL est conforme à de nombreuses normes du secteur. Par exemple, vous pouvez utiliser des bases de données RDS for MySQL afin de développer des applications conformes à la loi HIPAA. Vous pouvez utiliser les bases de données RDS for MySQL pour y stocker les informations relatives à la santé, y compris les données de santé protégées (PHI, Protected Health Information) selon les termes d'un accord de partenariat (BAA, Business Associate Agreement) avec AWS. Amazon RDS for MySQL respecte également les exigences de sécurité du Programme fédéral de gestion des risques et des autorisations (FedRAMP). De plus, Amazon RDS for MySQL a obtenu auprès du conseil d'autorisation commun (Joint Authorization Board, JAB) l'autorisation provisoire d'opérer (Provisional Authority to Operate, P-ATO) à niveau d'impact élevé du FedRAMP au sein des régions AWS GovCloud (US). Pour plus d’informations sur les normes de conformité prises en charge, consultez [Conformité du Cloud AWS](https://aws.amazon.com/compliance/).
Pour plus d'informations sur les fonctions de chaque version MySQL, consultez [The Main Features of MySQL](https://dev.mysql.com/doc/refman/8.0/en/features.html) dans la documentation MySQL.
Avant de créer une instance de base de données, effectuez les étapes de la section [Configuration de votre environnement Amazon RDS](CHAP_SettingUp.md). Lorsque vous créez une instance de base de données, l'utilisateur principal RDS obtient des privilèges d'administrateur de base de données (avec certaines restrictions). Utilisez ce compte pour des tâches administratives telles que la création de comptes de base de données supplémentaires.
Vous pouvez créer ce qui suit :
+ Instances DB
+ Instantanés de base de données
+ Restaurations à un instant donné
+ Sauvegardes automatiques
+ Sauvegardes manuelles
Vous pouvez utiliser des instances de base de données exécutant MySQL dans un cloud privé virtuel (VPC) basé sur Amazon VPC. Vous pouvez également ajouter des fonctionnalités à votre instance de base de données MySQL en activant diverses options. Amazon RDS prend en charge les déploiements multi-AZ pour MySQL comme solution de basculement haute disponibilité.
**Important**
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 nécessitent des privilèges avancés. Vous pouvez accéder à votre base de données en utilisant des client SQL standard tels que le client mysql. Toutefois, vous ne pouvez pas accéder directement à l’hôte en utilisant Telnet ou Secure Shell (SSH).
**Topics**
+ [
# Fonctionnalités MySQL prises en charge sur Amazon RDS
](MySQL.Concepts.FeatureSupport.md)
+ [
# Versions de MySQL sur Amazon RDS
](MySQL.Concepts.VersionMgmt.md)
+ [
# Connexion à votre instance de base de données MySQL
](USER_ConnectToInstance.md)
+ [
# Sécurisation des connexions d'instance de base de données MySQL
](securing-mysql-connections.md)
+ [
# Amélioration des performances des requêtes pour RDS for MySQL avec Lectures optimisées pour Amazon RDS
](rds-optimized-reads.md)
+ [
# Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL
](rds-optimized-writes.md)
+ [
# Mises à niveau du moteur de base de données RDS for MySQL
](USER_UpgradeDBInstance.MySQL.md)
+ [
# Mise à niveau d’une version du moteur d’instantané de base de données MySQL
](mysql-upgrade-snapshot.md)
+ [
# Importation de données dans une instance de base de données Amazon RDS for MySQL
](MySQL.Procedural.Importing.Other.md)
+ [
# Utilisation de la réplication MySQL dans Amazon RDS
](USER_MySQL.Replication.md)
+ [
# Configuration de clusters actifs-actifs pour RDS for MySQL
](mysql-active-active-clusters.md)
+ [
# Exportation de données à partir d'une instance DB MySQL grâce à la réplication
](MySQL.Procedural.Exporting.NonRDSRepl.md)
+ [
# Options pour les instances de base de données MySQL
](Appendix.MySQL.Options.md)
+ [
# Paramètres pour MySQL
](Appendix.MySQL.Parameters.md)
+ [
# Tâches DBA courantes pour les instances de base de données MySQL
](Appendix.MySQL.CommonDBATasks.md)
+ [
# Fuseau horaire local pour les instances de bases de données MySQL
](MySQL.Concepts.LocalTimeZone.md)
+ [
# Limites et problèmes connus pour Amazon RDS for MySQL
](MySQL.KnownIssuesAndLimitations.md)
+ [
# Référence des procédures stockées RDS pour MySQL
](Appendix.MySQL.SQLRef.md)
# Fonctionnalités MySQL prises en charge sur Amazon RDS
RDS for MySQL prend en charge la plupart des fonctionnalités et des capacités de MySQL. Certaines fonctions peuvent avoir une prise en charge limitée ou des privilèges restreints.
Vous pouvez filtrer les nouvelles fonctions de Amazon RDS sur la page [Nouveautés en matière de base de données](https://aws.amazon.com/about-aws/whats-new/database/). Pour **Produits**, choisissez **Amazon RDS**. Ensuite, effectuez une recherche à l’aide de mots clés tels que **MySQL 2022**.
**Note**
Les listes suivantes ne sont pas exhaustives.
**Topics**
+ [
## Prise en charge de la fonctionnalité MySQL sur les versions majeures Amazon RDS for MySQL
](#MySQL.Concepts.FeatureSupport.MajorVersions)
+ [
## Moteurs de stockage pris en charge pour RDS for MySQL
](#MySQL.Concepts.Storage)
+ [
## Utilisation de memcached et d'autres options avec MySQL sur Amazon RDS
](#MySQL.Concepts.General.Options)
+ [
## Préparation du cache InnoDB pour MySQL sur Amazon RDS
](#MySQL.Concepts.InnoDBCacheWarming)
+ [
## Changements de langue inclusifs pour RDS for MySQL 8.4
](#mysql-8-4-inclusive-language-changes)
+ [
## Fonctions MySQL non prises en charge par Amazon RDS
](#MySQL.Concepts.Features)
## Prise en charge de la fonctionnalité MySQL sur les versions majeures Amazon RDS for MySQL
Dans les sections suivantes, trouvez des informations sur la prise en charge de la fonction MySQL sur les versions majeures d’Amazon RDS for MySQL :
**Topics**
+ [
### Prise en charge de MySQL 8.4 sur Amazon RDS
](#MySQL.Concepts.FeatureSupport.8-4)
Pour en savoir plus sur les versions mineures prises en charge d’Amazon RDS for MySQL, consultez [Versions de MySQL mineures prises en charge sur Amazon RDS](MySQL.Concepts.VersionMgmt.md#MySQL.Concepts.VersionMgmt.Supported).
### Prise en charge de MySQL 8.4 sur Amazon RDS
Amazon RDS prend en charge les nouvelles fonctionnalités suivantes pour vos instances de base de données exécutant MySQL version 8.4 ou versions ultérieures.
+ **Bibliothèque cryptographique** — RDS pour MySQL a remplacé OpenSSL par AWS Libcrypto (AWS-LC), qui est certifié FIPS 140-3. Pour plus d'informations, consultez le AWS-LC GitHub référentiel à l'adresse[https://github.com/aws/aws-lc](https://github.com/aws/aws-lc).
+ **Changements TLS** : RDS for MySQL prend uniquement en charge les protocoles TLS 1.2 et TLS 1.3. Pour de plus amples informations, veuillez consulter [Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS](MySQL.Concepts.SSLSupport.md).
+ **Prise en charge de memcached** : l’interface memcached n’est plus disponible dans MySQL 8.4. Pour de plus amples informations, veuillez consulter [Prise en charge memcached MySQL](Appendix.MySQL.Options.memcached.md).
+ **Plugin d’authentification par défaut** : le plugin d’authentification par défaut est`caching_sha2_password`. Pour de plus amples informations, veuillez consulter [Plugin d’authentification par défaut MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin).
+ **Utilitaire client `mysqlpump`** : l’utilitaire client `mysqlpump` n’est plus disponible dans MySQL 8.4. Pour plus d’informations, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md) et [mysqldump et mysqlpump](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/mysqldump-and-mysqlpump.html) dans le *Guide prescriptif AWS *.
+ **Procédures stockées de réplication gérée** : lorsque vous utilisez des procédures stockées pour gérer la réplication avec un utilisateur de réplication configuré avec `caching_sha2_password`, vous devez configurer le protocole TLS en spécifiant `SOURCE_SSL=1`. `caching_sha2_password` est le plugin d’authentification par défaut pour RDS for MySQL 8.4.
+ **Modifications du comportement des paramètres** : les paramètres suivants ont été modifiés pour MySQL 8.4.
+ `innodb_dedicated_server` : ce paramètre est désormais activé par défaut. Pour de plus amples informations, veuillez consulter [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).
+ `innodb_buffer_pool` : le moteur de base de données calcule désormais ce paramètre, mais vous pouvez le remplacer. Pour de plus amples informations, veuillez consulter [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).
+ `innodb_redo_log_capacity` : ce paramètre contrôle désormais la taille des fichiers de journalisation de rétablissement. Le moteur de base de données calcule désormais ce paramètre, mais vous pouvez le remplacer. Pour de plus amples informations, veuillez consulter [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).
+ **Paramètres obsolètes ou supprimés** : RDS for MySQL a supprimé les paramètres suivants des groupes de paramètres pour les instances de base de données MySQL 8.4. Le paramètre `innodb_redo_log_capacity` contrôle désormais la taille des fichiers de journalisation de rétablissement.
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ **Nouvelles valeurs par défaut pour les paramètres** : les paramètres suivants ont de nouvelles valeurs par défaut pour les instances de base de données MySQL 8.4 :
+ Divers paramètres de la communauté MySQL liés aux performances ont été modifiés. Pour plus d’informations, consultez [Nouveautés dans MySQL 8.4 depuis MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html).
Nous vous recommandons de tester les performances de votre application sur RDS for MySQL 8.4 avant de migrer une instance de production.
+ `innodb_purge_threads` : la valeur par défaut est définie sur la formule `LEAST({DBInstanceVCPU/2},4)` pour éviter que la longueur de la liste d’historique d’InnoDB ne devienne trop longue.
+ `group_replication_exit_state_action` : la valeur par défaut est `OFFLINE_MODE`, ce qui correspond à la valeur par défaut dans MySQL Community. Pour de plus amples informations, veuillez consulter [Considérations et bonnes pratiques relatives aux clusters actifs-actifs RDS for MySQL](mysql-active-active-clusters-considerations-limitations.md#mysql-active-active-clusters-considerations).
+ `binlog_format` : la valeur par défaut est `ROW`, ce qui correspond à la valeur par défaut dans MySQL Community. Vous pouvez modifier le paramètre pour les instances de base de données mono-AZ ou multi-AZ, mais pas pour les clusters de bases de données multi-AZ. Les clusters de bases de données multi-AZ utilisent la réplication semi-synchrone, et lorsque `binlog_format` est défini sur `MIXED` ou `STATEMENT`, la réplication échoue.
+ **Changements de langage inclusifs** : RDS for MySQL 8.4 inclut des modifications depuis RDS for MySQL 8.0 liées aux mots-clés et aux schémas de système pour un langage inclusif. Pour de plus amples informations, veuillez consulter [Changements de langue inclusifs pour RDS for MySQL 8.4](#mysql-8-4-inclusive-language-changes).
Pour obtenir la liste de toutes les fonctionnalités et modifications apportées à MySQL 8.4, consultez [Nouveautés de MySQL 8.4 depuis MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) dans la documentation MySQL.
Pour obtenir la liste des fonctions non prises en charge, consultez [Fonctions MySQL non prises en charge par Amazon RDS](#MySQL.Concepts.Features).
## Moteurs de stockage pris en charge pour RDS for MySQL
Même si MySQL prend en charge plusieurs moteurs de stockage aux capacités diverses, ils ne sont pas tous optimisés pour la récupération et la durabilité des données. Amazon RDS prend entièrement en charge le moteur de stockage InnoDB pour les instances de base de données MySQL. Les fonctionnalités Amazon RDS telles que la Point-In-Time restauration et la restauration de snapshots nécessitent un moteur de stockage récupérable et sont prises en charge uniquement par le moteur de stockage InnoDB. Pour de plus amples informations, veuillez consulter [Prise en charge memcached MySQL](Appendix.MySQL.Options.memcached.md).
Le Federated Storage Engine n'est pour l'instant pas pris en charge par Amazon RDS for MySQL.
Pour les schémas créés par l'utilisateur, le moteur de stockage MyISAM ne permet pas une restauration fiable et peut entraîner la perte ou la corruption de données lorsque MySQL est redémarré après une restauration, empêchant ainsi la Point-In-Time restauration ou la restauration par capture instantanée de fonctionner comme prévu. Néanmoins, si vous choisissez tout de même d'utiliser MyISAM avec Amazon RDS, les instantanés peuvent être utiles dans certaines conditions.
**Note**
Les tables système du schéma `mysql` peuvent être dans le stockage MyISAM.
Si vous souhaitez convertir des tables MyISAM existantes en tables InnoDB, vous pouvez utiliser la commande `ALTER TABLE` (par exemple, `alter table TABLE_NAME engine=innodb;`). N'oubliez pas que MyISAM et InnoDB ont des forces et des faiblesses différentes, vous devriez donc commencer par évaluer de façon exhaustive l'impact de ce basculement sur vos applications.
Les versions MySQL 5.1, 5.5 et 5.6 ne sont plus prises en charge dans Amazon RDS. Cependant, vous pouvez restaurer des instantanés MySQL 5.1, 5.5 et 5.6 existants. Lorsque vous restaurez un instantané MySQL 5.1, 5.5 ou 5.6, l'instance de base de données est automatiquement mise à niveau vers MySQL 5.7.
## Utilisation de memcached et d'autres options avec MySQL sur Amazon RDS
La plupart des moteurs de base de données Amazon RDS prennent en charge des groupes d'options qui vous permettent de sélectionner des fonctions supplémentaires pour votre instance de base de données. Les instances de bases de données RDS for MySQL prennent en charge l'option `memcached`, un cache simple basée sur les clés. Pour plus d'informations sur `memcached` et d'autres options, consultez [Options pour les instances de base de données MySQL](Appendix.MySQL.Options.md). Pour plus d’informations sur l’utilisation de groupes d’options, consultez [Utilisation de groupes d’options](USER_WorkingWithOptionGroups.md).
## Préparation du cache InnoDB pour MySQL sur Amazon RDS
La préparation du cache InnoDB peut fournir des gains de performances pour votre instance de base de données MySQL en enregistrant l’état actuel du groupe de mémoires tampons lorsque l’instance de base de données est arrêtée, puis en rechargeant le groupe de mémoires tampons à partir des informations enregistrées au démarrage de l’instance de base de données. Cette approche contourne la nécessité de « préparer » le groupe de mémoires tampons à partir d’une utilisation normale de la base de données et précharge à la place le groupe de mémoires tampons avec les pages des requêtes courantes connues. Le fichier qui stocke les informations du groupe de mémoires tampons enregistré stocke uniquement les métadonnées pour les pages qui sont dans le groupe de mémoires tampons et pas les pages elles-mêmes. Par conséquent, le fichier ne nécessite pas un important espace de stockage. La taille du fichier représente environ 0,2 pour cent de la taille du cache. Par exemple, pour un cache 64 Gio, la taille du fichier de préparation de cache est de 128 Mio. Pour plus d’informations sur la préparation du cache InnoDB, consultez [Saving and Restoring the Buffer Pool State](https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html) dans la documentation MySQL.
Les instances de bases de données RDS for MySQL prennent en charge la préparation du cache InnoDB. Pour activer la préparation du cache InnoDB, définissez les paramètres `innodb_buffer_pool_dump_at_shutdown` et `innodb_buffer_pool_load_at_startup` avec la valeur 1 dans le groupe de paramètres de votre instance de base de données. La modification de ces valeurs dans un groupe de paramètres affecte toutes les instances de bases de données MySQL qui utilisent ce groupe de paramètres. Pour activer la préparation du cache InnoDB pour des instances de bases de données MySQL spécifiques, vous devrez peut-être créer un groupe de paramètres pour ces instances. Pour plus d'informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
La préparation du cache InnoDB fournit principalement une amélioration des performances pour les instances de bases de données qui utilisent le stockage standard. Si vous utilisez le stockage PIOPS, vous ne constatez généralement pas d'amélioration significative des performances.
**Important**
Si votre instance de base de données MySQL ne se ferme pas normalement, comme lors d’un basculement, l’état du groupe de mémoires tampons n’est pas enregistré sur le disque. Dans ce cas, MySQL charge n’importe quel fichier du groupe de mémoires tampons disponible au redémarrage de l’instance de base de données. Il n’en résulte aucun dommage, mais le groupe de mémoires tampons restauré peut ne pas refléter l’état le plus récent du groupe de mémoires tampons avant le redémarrage. Pour vous assurer d’avoir un état récent du groupe de mémoires tampons disponible afin de préparer le cache InnoDB au démarrage, il est recommandé que vous vidiez régulièrement le groupe de mémoires tampons « à la demande ».
Vous pouvez créer un événement pour vider le groupe de mémoires tampons automatiquement et à intervalles réguliers. Par exemple, l’instruction suivante crée un événement nommé `periodic_buffer_pool_dump` qui vide le groupe de mémoires tampons toutes les heures.
```
1. CREATE EVENT periodic_buffer_pool_dump
2. ON SCHEDULE EVERY 1 HOUR
3. DO CALL mysql.rds_innodb_buffer_pool_dump_now();
```
Pour plus d’informations sur les événements MySQL, consultez [Syntaxe d’événement](https://dev.mysql.com/doc/refman/8.0/en/events-syntax.html) dans la documentation MySQL.
### Vidage et chargement du groupe de mémoires tampons à la demande
Vous pouvez enregistrer et charger le cache InnoDB « à la demande ».
+ Pour vider l’état actuel du groupe de mémoires tampons sur le disque, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_dump_now).
+ Pour charger l’état enregistré du groupe de mémoires tampons à partir du disque, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_now).
+ Pour annuler une opération de chargement en cours, appelez la procédure stockée [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort).
## Changements de langue inclusifs pour RDS for MySQL 8.4
RDS for MySQL 8.4 inclut des modifications depuis l’édition communautaire MySQL 8.4 liées aux mots-clés et aux schémas de système pour un langage inclusif. Par exemple, la commande `SHOW REPLICA STATUS` remplace `SHOW SLAVE STATUS`.
**Topics**
+ [
### Modifications du nom de paramètre de configuration
](#mysql-8-4-inclusive-language-changes-params)
+ [
### Changements de nom de procédure stockée
](#mysql-8-4-inclusive-language-changes-sp)
### Modifications du nom de paramètre de configuration
Les paramètres de configuration suivants portent de nouveaux noms dans RDS for MySQL 8.4.
Pour des raisons de compatibilité, vous pouvez vérifier les noms des paramètres dans le client `mysql` en utilisant l’un ou l’autre des noms. Vous pouvez uniquement utiliser les nouveaux noms lorsque vous modifiez les valeurs dans un groupe de paramètres MySQL 8.4 personnalisés. Pour de plus amples informations, veuillez consulter [Groupes de paramètres par défaut et personnalisés](parameter-groups-overview.md#parameter-groups-overview.custom).
| Nom à supprimer | Nom nouveau ou préféré |
| --- | --- |
| `init_slave` | `init_replica` |
| `log_slave_updates` | `log_replica_updates` |
| `log_slow_slave_statements` | `log_slow_replica_statements` |
| `rpl_stop_slave_timeout` | `rpl_stop_replica_timeout` |
| `skip_slave_start` | `skip_replica_start` |
| `slave_checkpoint_group` | `replica_checkpoint_group` |
| `slave_checkpoint_period` | `replica_checkpoint_period` |
| `slave_compressed_protocol` | `replica_compressed_protocol` |
| `slave_exec_mode` | `replica_exec_mode` |
| `slave_load_tmpdir` | `replica_load_tmpdir` |
| `slave_max_allowed_packet` | `replica_max_allowed_packet` |
| `slave_net_timeout` | `replica_net_timeout` |
| `slave_parallel_type` | `replica_parallel_type` |
| `slave_parallel_workers` | `replica_parallel_workers` |
| `slave_pending_jobs_size_max` | `replica_pending_jobs_size_max` |
| `slave_preserve_commit_order` | `replica_preserve_commit_order` |
| `slave_skip_errors` | `replica_skip_errors` |
| `slave_sql_verify_checksum` | `replica_sql_verify_checksum` |
| `slave_transaction_retries` | `replica_transaction_retries` |
| `slave_type_conversions` | `replica_type_conversions` |
| `sql_slave_skip_counter` | `sql_replica_skip_counter` |
**Note**
Le paramètre `replica_allow_batching` n’est pas disponible, car Amazon RDS ne prend pas en charge les clusters NDB.
### Changements de nom de procédure stockée
Les procédures stockées suivantes portent de nouveaux noms dans RDS for MySQL 8.4.
Pour des raisons de compatibilité, vous pouvez utiliser l’un ou l’autre des noms dans la version initiale de RDS for MySQL 8.4. Les anciens noms de procédures seront supprimés dans une version ultérieure. Pour de plus amples informations, veuillez consulter [Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)](mysql-stored-proc-replicating.md).
| Nom à supprimer | Nom nouveau ou préféré |
| --- | --- |
| `mysql.rds_next_master_log` | `mysql.rds_next_source_log ` |
| `mysql.rds_reset_external_master` | `mysql.rds_reset_external_source` |
| `mysql.rds_set_external_master` | `mysql.rds_set_external_source` |
| `mysql.rds_set_external_master_with_auto_position` | `mysql.rds_set_external_source_with_auto_position` |
| `mysql.rds_set_external_master_with_delay` | `mysql.rds_set_external_source_with_delay` |
| `mysql.rds_set_master_auto_position` | `mysql.rds_set_source_auto_position` |
## Fonctions MySQL non prises en charge par Amazon RDS
Amazon RDS ne prend pas en charge actuellement les fonctions MySQL suivantes :
+ Plug-in d'authentification
+ Erreur de journalisation dans le journal système
+ Chiffrement d'espace de tables InnoDB
+ Clusters NDB
+ Plug-in de niveau de sécurité du mot de passe
+ Variables système persistantes
+ Plugin de réécriture de requêtes Rewriter
+ Réplication semi-synchrone, sauf pour les clusters de bases de données multi-AZ
+ Espace de table transportable
+ Plug-in X
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. Amazon RDS prend en charge l'accès aux bases de données sur une instance de base de données en utilisant toute application cliente SQL standard. Amazon RDS ne permet pas d’accès d’hôte direct à une instance de base de données via Telnet, Secure Shell (SSH) ou une connexion Bureau à distance Windows. Lorsque vous créez une instance de base de données, *db\$1owner* vous est attribué pour toutes les bases de données sur cette instance, et vous disposez de toutes les autorisations au niveau de la base de données, sauf celles qui sont utilisées pour les sauvegardes. Amazon RDS gère les sauvegardes pour vous.
# Versions de MySQL sur Amazon RDS
Dans MySQL, les numéros de version sont organisés en versions X.Y.Z. Dans la terminologie Amazon RDS, X.Y indique la version majeure et Z le numéro de la version mineure. Pour les implémentations Amazon RDS, un changement de version sera considéré majeur si le numéro de version majeure change—par exemple, en passant de la version 5.7 à 8.0. Un changement de version sera considéré comme mineur si seul le numéro de la version mineure change, par exemple, en passant de la version 8.0.32 à 8.0.34.
**Topics**
+ [
## Versions de MySQL mineures prises en charge sur Amazon RDS
](#MySQL.Concepts.VersionMgmt.Supported)
+ [
## Versions de MySQL majeures prises en charge sur Amazon RDS
](#MySQL.Concepts.VersionMgmt.ReleaseCalendar)
+ [
## Versions de Support étendu Amazon RDS pour RDS for MySQL
](#mysql-extended-support-releases)
+ [
## Utilisation de l’environnement de version préliminaire de base de données
](#mysql-working-with-the-database-preview-environment)
+ [
## MySQL version 9.5 dans l'environnement Database Preview
](#mysql-preview-environment-version-9-5)
+ [
## MySQL version 9.4 dans l'environnement Database Preview
](#mysql-preview-environment-version-9-4)
+ [
## MySQL version 9.3 dans l’environnement de version préliminaire de base de données
](#mysql-preview-environment-version-9-3)
+ [
## Versions rendues obsolètes pour Amazon RDS for MySQL
](#MySQL.Concepts.DeprecatedVersions)
## Versions de MySQL mineures prises en charge sur Amazon RDS
Amazon RDS prend actuellement en charge les versions mineures suivantes de MySQL.
**Note**
Amazon RDS Extended Support n’est pas disponible pour les versions mineures.
Le tableau suivant indique les versions mineures de MySQL 8.4 actuellement prises en charge par Amazon RDS.
| Version du moteur MySQL | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 8.4.8 | 20 janvier 2026 | 3 février 2026 | 3 février 2027 |
| 8.4.7 | 21 octobre 2025 | 13 novembre 2025 | 30 novembre 2026 |
| 8.4.6 | 22 juillet 2025 | 1er août 2025 | 30 septembre 2026 |
| 8.4.5 | 15 avril 2025 | 29 avril 2025 | 30 septembre 2026 |
| 8.4.4 | 21 janvier 2025 | 19 février 2025 | 31 mai 2026 |
| 8.4.3 | 15 octobre 2024 | 21 novembre 2024 | 31 mai 2026 |
Le tableau suivant indique les versions mineures de MySQL 8.0 actuellement prises en charge par Amazon RDS.
**Note**
Les versions mineures peuvent atteindre la fin du support standard avant les versions majeures. Par exemple, la version mineure 8.0.28 a atteint sa date de fin de support standard le 28 mars 2024, tandis que la version majeure 8.0 atteindra cette date le 31 juillet 2026. RDS prendra en charge les versions mineures 8.0.\$1 supplémentaires publiées par la communauté MySQL entre ces dates. Nous vous recommandons de passer à la dernière version mineure disponible aussi souvent que possible pour toutes les versions majeures.
| Version du moteur MySQL | Date de parution communautaire | Date de parution de RDS | Date de fin du support standard de RDS |
| --- | --- | --- | --- |
| 8,0,45 | 20 janvier 2026 | 3 février 2026 | 31 juillet 2026 |
| 8,0,44 | 21 octobre 2025 | 13 novembre 2025 | 31 juillet 2026 |
| 8,0,43 | 22 juillet 2025 | 1er août 2025 | 31 juillet 2026 |
| 8,0,42 | 15 avril 2025 | 29 avril 2025 | 31 juillet 2026 |
| 8,0,41 | 21 janvier 2025 | 19 février 2025 | 31 mai 2026 |
| 8,0,40 | 15 octobre 2024 | 13 novembre 2024 | 31 mai 2026 |
Le tableau suivant indique les versions mineures de MySQL 5.7 disponibles avec le support étendu Amazon RDS.
**Note**
Les versions mineures peuvent atteindre la fin du support étendu avant les versions majeures. Par exemple, la version mineure 5.7.44-RDS.20240529 atteint la date de fin du support étendu en septembre 2025, tandis que la version majeure 5.7 atteint cette date le 28 février 2027. RDS générera et publiera des versions mineures 5.7.44-RDS.xxyyzz supplémentaires entre ces dates. Nous vous recommandons de passer à la dernière version mineure disponible aussi souvent que possible pour toutes les versions majeures.
| Version du moteur MySQL | Date de parution communautaire | Date de parution de RDS | Date de fin du support étendu RDS |
| --- | --- | --- | --- |
| 5.7.44-RDS.20260212\$1 | Non applicable | 26 février 2026 | 28 février 2027 |
| 5.7.44-RDS.20251212\$1 | Non applicable | 12 décembre 2025 | 30 décembre 2026 |
| 5.7.44-RDS.20250818\$1 | Non applicable | 15 septembre 2025 | 30 septembre 2026 |
| 5.7.44-RDS.20250508\$1 | Non applicable | 20 mai 2025 | 30 septembre 2026 |
| 5.7.44-RDS.20250213\$1 | Non applicable | 12 mars 2025 | 30 septembre 2026 |
| 5.7.44-RDS.20250103\$1 | Non applicable | 13 février 2025 | 31 mai 2026 |
\$1 MySQL Community a mis hors service la version majeure 5.7 et ne publiera pas de nouvelles versions mineures. Il s’agit d’une version mineure publiée par Amazon RDS avec des correctifs de sécurité critiques et des corrections de bugs pour les bases de données MySQL 5.7 couvertes par le support étendu RDS. Pour plus d’informations sur la prise en charge de ces versions mineures, consultez [Versions de Support étendu Amazon RDS pour RDS for MySQL](#mysql-extended-support-releases). Pour plus d’informations sur le support étendu RDS, consultez [Support étendu Amazon RDS avec Amazon RDS](extended-support.md).
Vous pouvez spécifier n'importe quelle version MySQL actuellement prise en charge lorsque vous créez une instance de base de données. Vous pouvez spécifier la version majeure (par exemple MySQL 5.7), puis toute version mineure prise en charge pour la version majeure spécifiée. Si aucune version n'est spécifiée, Amazon RDS utilise par défaut une version prise en charge, généralement la plus récente. Si une version majeure est spécifiée, mais qu’une version mineure ne l’est pas, Amazon RDS utilise par défaut une version récente de la version majeure que vous avez spécifiée. Pour voir la liste des versions prises en charge, ainsi que les valeurs par défaut pour les instances de base de données nouvellement créées, exécutez la [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI commande.
Par exemple, pour répertorier les versions de moteur prises en charge pour RDS for MySQL, exécutez la commande CLI suivante :
```
aws rds describe-db-engine-versions --engine mysql --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
La version par défaut de MySQL peut varier selon la Région AWS. Pour créer une instance de base de données avec une version mineure spécifique, spécifiez la version mineure lors de la création de l’instance de base de données. Vous pouvez déterminer la version mineure par défaut pour un Région AWS en exécutant la AWS CLI commande suivante :
```
aws rds describe-db-engine-versions --default-only --engine mysql --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
*major\$1engine\$1version*Remplacez-le par la version principale du moteur, puis remplacez *region* par le Région AWS. Par exemple, la AWS CLI commande suivante renvoie la version mineure du moteur MySQL par défaut pour la version majeure 5.7 et pour l'ouest des États-Unis (Oregon) Région AWS (us-west-2) :
```
aws rds describe-db-engine-versions --default-only --engine mysql --engine-version 5.7 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text
```
Avec Amazon RDS, vous contrôlez à quel moment vous mettez à niveau votre instance MySQL vers une nouvelle version majeure prise en charge par Amazon RDS. Vous pouvez maintenir la compatibilité avec des versions MySQL spécifiques, tester de nouvelles versions avec votre application avant le déploiement en production et effectuer des mises à niveau de versions majeures aux moments qui correspondent le mieux à votre calendrier.
Lorsque la mise à niveau automatique de versions mineures est activée, votre instance de base de données sera automatiquement mise à niveau vers de nouvelles versions mineures MySQL, celles-ci étant prises en charge par Amazon RDS. Ces correctifs sont appliqués pendant le créneau de maintenance planifié. Vous pouvez modifier une instance de base de données pour activer ou désactiver les mises à niveau automatiques des versions mineures.
Si vous refusez les mises à niveau automatiques planifiées, vous pouvez procéder manuellement à une mise à niveau vers une version mineure prise en charge en suivant la même procédure que pour une mise à jour de la version majeure. Pour plus d'informations, consultez [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
Amazon RDS prend actuellement en charge les mises à niveau sur place des versions majeures suivantes du moteur de base de données MySQL :
+ MySQL 5.7 vers MySQL 8.0
+ MySQL 8.0 vers MySQL 8.4
Étant donné que les mises à niveau de version majeures impliquent quelques risques de compatibilité, elles ne sont pas appliquées automatiquement et vous devez donc faire une demande de modification de l'instance de base de données. Vous devez tester soigneusement toute mise à niveau avant de procéder à la mise à niveau de vos instances de production. Pour plus d'informations sur la mise à niveau d'une instance de base de données MySQL, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
Vous pouvez tester une instance de base de données par rapport à une nouvelle version avant la mise à niveau. Pour ce faire, créez un instantané de base de données de votre instance de base de données existante, restaurez à partir de l'instantané de base de données pour créer une instance de base de données et lancez une mise à niveau de version pour la nouvelle instance de base de données. Vous pouvez ensuite procéder en toute sécurité à une expérimentation sur le clone mis à niveau de votre instance de base de données avant de décider de mettre à niveau ou pas votre instance de base de données d'origine.
### Versions de MySQL mineures sur Amazon RDS
Pour les modifications apportées par la communauté MySQL aux versions mineures, consultez [Mises à jour critiques, alertes de sécurité et bulletins](https://www.oracle.com/security-alerts/) sur le site web d’Oracle. Sous **Mise à jour de correctif critique**, choisissez le mois où Oracle a publié la version mineure. Ensuite, choisissez la version mineure de MySQL sous **Produits et versions concernés**.
**Topics**
+ [
#### MySQL version 8.4.8
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.8)
+ [
#### MySQL version 8.4.7
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.7)
+ [
#### MySQL version 8.4.6
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.6)
+ [
#### MySQL version 8.4.5
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.5)
+ [
#### MySQL version 8.4.4
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.4)
+ [
#### MySQL version 8.0.45
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.45)
+ [
#### MySQL version 8.0.44
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.44)
+ [
#### MySQL version 8.0.43
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.43)
+ [
#### MySQL version 8.0.42
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.42)
+ [
#### MySQL version 8.0.41
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.41)
+ [
#### MySQL version 8.0.40
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.40)
+ [
#### MySQL version 8.0.39
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.39)
+ [
#### MySQL version 8.0.37
](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.37)
#### MySQL version 8.4.8
MySQL version 8.4.8 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### MySQL version 8.4.7
MySQL version 8.4.7 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
#### MySQL version 8.4.6
MySQL version 8.4.6 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
#### MySQL version 8.4.5
MySQL version 8.4.5 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MySQL version 8.4.4
MySQL version 8.4.4 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
+ Correction d’un bug qui provoquait une erreur de classement lors de l’exécution des procédures stockées Amazon RDS `mysql.rds_set_configuration` et `mysql.rds_kill`.
#### MySQL version 8.0.45
MySQL version 8.0.45 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025c`.
+ Correction d'un problème qui empêchait certaines instructions SQL d'être enregistrées dans le journal d'audit.
#### MySQL version 8.0.44
MySQL version 8.0.44 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
#### MySQL version 8.0.43
MySQL version 8.0.43 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
#### MySQL version 8.0.42
MySQL version 8.0.42 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025b`.
#### MySQL version 8.0.41
MySQL version 8.0.41 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Les informations de fuseau horaire ont été mises à jour pour les baser sur `tzdata2025a`.
+ Correction d’un bug qui provoquait une erreur de classement lors de l’exécution des procédures stockées Amazon RDS `mysql.rds_set_configuration` et `mysql.rds_kill`.
#### MySQL version 8.0.40
MySQL version 8.0.40 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Correction d’un bug provoquant des erreurs de correspondance entre les jeux de caractères lors des mises à niveau de base de données.
#### MySQL version 8.0.39
MySQL version 8.0.39 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Correction d’un bug qui empêchait le bon fonctionnement de `sql_log_off` avec le privilège `SESSION_VARIABLES_ADMIN`.
+ Correction d’un bug qui empêchait l’utilisateur principal d’accorder le privilège `SESSION_VARIABLE_ADMIN` aux autres utilisateurs de la base de données.
+ Correction d’un bug qui provoquait un mélange illégal de classements lors de l’exécution des procédures stockées fournies par RDS.
#### MySQL version 8.0.37
MySQL version 8.0.37 est désormais disponible sur Amazon RDS. Cette version contient des correctifs et des améliorations ajoutés par la communauté MySQL et Amazon RDS.
**Nouvelles fonctionnalités et améliorations**
+ Correction d’un bug lié à l’exécution d’une instruction DDL instantanée suivie d’une MISE À JOUR qui entraînait un échec d’assertion.
## Versions de MySQL majeures prises en charge sur Amazon RDS
Les versions majeures de RDS for MySQL sont disponibles sous le support standard au moins jusqu'à la fin de vie de la version correspondante de la communauté. Vous pouvez continuer à exécuter une version majeure après la date de fin du support standard RDS moyennant des frais. Pour plus d'informations, consultez [Support étendu Amazon RDS avec Amazon RDS](extended-support.md) et [Tarification d'Amazon RDS for MySQL](https://aws.amazon.com/rds/mysql/pricing/).
Vous pouvez utiliser les dates suivantes pour planifier vos cycles de test et de mise à niveau.
**Note**
Vous pouvez également consulter les informations relatives aux dates de support des principales versions du moteur à l'aide de l'API AWS CLI ou de l'API RDS. Pour de plus amples informations, veuillez consulter [Affichage des dates de support pour les versions de moteur dans Support étendu Amazon RDS](extended-support-viewing-support-dates.md).
| Version majeure de MySQL | Date de parution communautaire | Date de parution de RDS | Date de fin de vie de la communauté | Date de fin de la prise en charge standard de RDS | Date de début de la première année de tarification du support étendu RDS | Date de début de la troisième année de tarification du support étendu RDS | Date de fin du support étendu RDS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| MySQL 8.4 | 30 avril 2024 | 21 novembre 2024 | 30 avril 2029 | 31 juillet 2029 | 1er août 2029 | 1er août 2031 | 31 juillet 2032 |
| MySQL 8.0 | 19 avril 2018 | 23 octobre 2018 | 30 avril 2026 | 31 juillet 2026 | 1er août 2026 | 1er août 2028 | 31 juillet 2029 |
| MySQL 5.7\$1 | 21 octobre 2015 | 22 février 2016 | 31 octobre 2023 | 29 février 2024 | 1er mars 2024 | 1er mars 2026 | 28 février 2027 |
\$1 MySQL 5.7 est désormais disponible uniquement avec le support étendu RDS. Pour de plus amples informations, veuillez consulter [Support étendu Amazon RDS avec Amazon RDS](extended-support.md).
## Versions de Support étendu Amazon RDS pour RDS for MySQL
Le contenu suivant répertorie toutes les versions du support étendu RDS pour les versions de RDS for MySQL.
**Topics**
+ [
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20260212
](#mysql-extended-support-releases-version-5.7.44-RDS.20260212)
+ [
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20251212
](#mysql-extended-support-releases-version-5.7.44-RDS.20251212)
+ [
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20250818
](#mysql-extended-support-releases-version-5.7.44-RDS.20250818)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250508
](#mysql-extended-support-releases-version-5.7.44-20250508)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250213
](#mysql-extended-support-releases-version-5.7.44-20250213)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250103
](#mysql-extended-support-releases-version-5.7.44-20250103)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240808
](#mysql-extended-support-releases-version-5.7.44-20240808)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240529
](#mysql-extended-support-releases-version-5.7.44-20240529)
+ [
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240408
](#mysql-extended-support-releases-version-5.7.44-20240408)
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20260212
Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20260212 est disponible.
**Bugs corrigés :**
+ Actualisez le certificat de test utilisé pour tester le correctif du bogue 22295186.
+ Corrige une fuite de mémoire avec un index de préfixe sur les colonnes blob.
**CVEs fixe :**
+ [CVE-2026-21936](https://nvd.nist.gov/vuln/detail/CVE-2026-21936)
+ [CVE-2026-21968](https://nvd.nist.gov/vuln/detail/CVE-2026-21968)
+ [CVE-2026-21941](https://nvd.nist.gov/vuln/detail/CVE-2026-21941)
+ [CVE-2026-21948](https://nvd.nist.gov/vuln/detail/CVE-2026-21948)
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20251212
Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20251212 est disponible.
**Bugs corrigés :**
+ Correction d'un problème de démarrage du serveur lorsque la taille du pool de mémoire tampon dépassait la limite supérieure.
+ Correction d'une erreur de lecture `INFORMATION_SCHEMA.INNODB_LOCKS` qui provoquait une fermeture anormale du serveur.
+ Correction d'un problème lié à la prise en charge des JUnit rapports dans MySQL Test Run (MTR).
+ Correction de problèmes de compilation lors de la construction avec `-DWITH_INNODB_MEMCACHED=ON` l'option.
+ Correction d'un problème lié à l'exécution de MySQL Test Run (MTR) pour le bogue 25182306.
**CVEs fixe :**
+ [CVE-2025-53054](https://nvd.nist.gov/vuln/detail/CVE-2025-53054)
+ [CVE-2025-53044](https://nvd.nist.gov/vuln/detail/CVE-2025-53044)
+ [CVE-2025-53045](https://nvd.nist.gov/vuln/detail/CVE-2025-53045)
+ [CVE-2025-53062](https://nvd.nist.gov/vuln/detail/CVE-2025-53062)
+ [CVE-2025-53040](https://nvd.nist.gov/vuln/detail/CVE-2025-53040)
+ [CVE-2025-53042](https://nvd.nist.gov/vuln/detail/CVE-2025-53042)
+ [CVE-2025-53067](https://nvd.nist.gov/vuln/detail/CVE-2025-53067)
### Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20250818
Support étendu RDS pour RDS pour MySQL version 5.7.44-RDS.20250818 est disponible.
**Bugs corrigés :**
+ Correction d'un problème en raison duquel le plugin de réécriture de requêtes échouait lorsque le serveur fonctionnait avec`autocommit=OFF`.
+ Correction d'un problème d'autorisation qui empêchait les versions de Debian et d'Ubuntu de fonctionner en mode rootless.
+ Correction d'une mise à jour manquante pour le bogue 30875669.
**CVEs fixe :**
+ [CVE-2025-50082](https://nvd.nist.gov/vuln/detail/CVE-2025-50082)
+ [CVE-2025-50083](https://nvd.nist.gov/vuln/detail/CVE-2025-50083)
+ [CVE-2025-50079](https://nvd.nist.gov/vuln/detail/CVE-2025-50079)
+ [CVE-2025-50084](https://nvd.nist.gov/vuln/detail/CVE-2025-50084)
+ [CVE-2025-50087](https://nvd.nist.gov/vuln/detail/CVE-2025-50087)
+ [CVE-2025-50091](https://nvd.nist.gov/vuln/detail/CVE-2025-50091)
+ [CVE-2025-50101](https://nvd.nist.gov/vuln/detail/CVE-2025-50101)
+ [CVE-2025-50102](https://nvd.nist.gov/vuln/detail/CVE-2025-50102)
+ [CVE-2025-50098](https://nvd.nist.gov/vuln/detail/CVE-2025-50098)
+ [CVE-2025-53023](hhttps://nvd.nist.gov/vuln/detail/CVE-2025-53023)
+ [CVE-2025-50081](https://nvd.nist.gov/vuln/detail/CVE-2025-50081)
+ [CVE-2025-50085](https://nvd.nist.gov/vuln/detail/CVE-2025-50085)
+ [CVE-2025-50077](https://nvd.nist.gov/vuln/detail/CVE-2025-50077)
+ [CVE-2025-50088](https://nvd.nist.gov/vuln/detail/CVE-2025-50088)
+ [CVE-2025-50092](https://nvd.nist.gov/vuln/detail/CVE-2025-50092)
+ [CVE-2025-50099](https://nvd.nist.gov/vuln/detail/CVE-2025-50099)
+ [CVE-2025-50096](https://nvd.nist.gov/vuln/detail/CVE-2025-50096)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250508
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250508 est désormais disponible.
**Bugs corrigés :**
+ Index virtuel fixe instable après la restauration lorsque `index_id` est supérieur au maximum `uint32`.
+ Les tests corrigés échouent en raison d’un problème de mémoire.
+ `` fixe est vide pour `Execute`.
+ Correction de la compilation MySQL avec GCC 14 [noclose 5.7].
**CVEs fixe :**
+ [CVE-2025-30682](https://nvd.nist.gov/vuln/detail/CVE-2025-30682)
+ [CVE-2025-30687](https://nvd.nist.gov/vuln/detail/CVE-2025-30687)
+ [CVE-2025-30688](https://nvd.nist.gov/vuln/detail/CVE-2025-30688)
+ [CVE-2025-21581](https://nvd.nist.gov/vuln/detail/CVE-2025-21581)
+ [CVE-2025-21585](https://nvd.nist.gov/vuln/detail/CVE-2025-21585)
+ [CVE-2025-30689](https://nvd.nist.gov/vuln/detail/CVE-2025-30689)
+ [CVE-2025-30722](https://nvd.nist.gov/vuln/detail/CVE-2025-30722)
+ [CVE-2025-21577](https://nvd.nist.gov/vuln/detail/CVE-2025-21577)
+ [CVE-2025-30693](https://nvd.nist.gov/vuln/detail/CVE-2025-30693)
+ [CVE-2025-30695](https://nvd.nist.gov/vuln/detail/CVE-2025-30695)
+ [CVE-2025-30703](https://nvd.nist.gov/vuln/detail/CVE-2025-30703)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250213
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250213 est désormais disponible.
**Bugs corrigés :**
+ Correction de l’échec de l’assertion d’InnoDB `result != FTS_INVALID`.
+ Correction du plantage et de la corruption généralisée des index spatiaux après que l’opération `ALTER TABLE` a reconstruit la table InnoDB à l’aide de l’algorithme `INPLACE`.
+ Correction de `ON DELETE CASCADE` avec les crash de la colonne générée dans `innobase_get_computed_value`.
+ Correction d’un échec d’assertion dans `row_MySQL_pad_col`.
+ Correction d’un problème à cause duquel le DDL en ligne provoquait l’erreur suivante : `ERROR 1712 (HY000): Index PRIMARY is corrupted`.
+ Correction de crashs à `Item_rollup_sum_switcher::current_arg`.
+ Correction d’un problème à cause duquel le cache de base de données n’était pas vidé sur `DROP USER`.
+ Correction d’un dépassement de la mémoire tampon dans `my_print_help`.
+ Correction d’un problème d’InnoDB à cause duquel l’index `FULLTEXT` limite `FTS_DOC_ID` à une valeur maximale de 32 bits non signée.
**CVEs fixe :**
+ [CVE-2025-21497](https://nvd.nist.gov/vuln/detail/CVE-2025-21497)
+ [CVE-2025-21555](https://nvd.nist.gov/vuln/detail/CVE-2025-21555)
+ [CVE-2025-21559](https://nvd.nist.gov/vuln/detail/CVE-2025-21559)
+ [CVE-2025-21490](https://nvd.nist.gov/vuln/detail/CVE-2025-21490)
+ [CVE-2025-21491](https://nvd.nist.gov/vuln/detail/CVE-2025-21491)
+ [CVE-2025-21500](https://nvd.nist.gov/vuln/detail/CVE-2025-21500)
+ [CVE-2025-21501](https://nvd.nist.gov/vuln/detail/CVE-2025-21501)
+ [CVE-2025-21540](https://nvd.nist.gov/vuln/detail/CVE-2025-21540)
+ [CVE-2025-21543](https://nvd.nist.gov/vuln/detail/CVE-2025-21543)
+ [CVE-2025-21520](https://nvd.nist.gov/vuln/detail/CVE-2025-21520)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250103
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20250103 est désormais disponible.
**Bugs corrigés :**
+ Correction d’un problème de nettoyage FTS lors de la suppression et de l’ajout d’un index `FULLTEXT` dans la même transaction.
+ Optimisation du temps d’allocation de mémoire dans le client MySQL pour éviter toute fuite potentielle.
+ Correction de la troncature des résultats à 34 octets lors de l’utilisation de l’opérateur `UNION`.
+ out-of-boundsAccès potentiel fixe `ulong bitmask` en raison du code d'autorisation.
**CVEs fixe :**
+ [CVE-2024-21230](https://nvd.nist.gov/vuln/detail/CVE-2024-21230)
+ [CVE-2024-21201](https://nvd.nist.gov/vuln/detail/CVE-2024-21201)
+ [CVE-2024-21241](https://nvd.nist.gov/vuln/detail/CVE-2024-21241)
+ [CVE-2024-21203](https://nvd.nist.gov/vuln/detail/CVE-2024-21203)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240808
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240808 est désormais disponible.
**Bugs corrigés :**
+ Correction d’un échec d’assertion lié à l’index des colonnes du dictionnaire.
+ Correction d’un problème lié à la fonction `is_binlog_cache_empty()`.
+ Correction d’erreurs `heap-use-after-free` dans les fichiers `sql/item.cc`.
+ Correction de plusieurs problèmes d’index spatial en les désactivant pour les lectures `index-only`.
+ Correction d’un problème d’instrumentation avec le plugin `LOCK_ORDER: CONNECTION_CONTROL`.
+ Correction de threads bloqués avec le plugin `CONNECTION_CONTROL`.
+ Correction de la non-mise à jour de `PSI_THREAD_INFO` pour `PREPARED STATEMENTS`.
+ Correction du double traitement des mots d’index FTS avec `innodb_optimize_fulltext_only`.
**CVEs fixe :**
+ [CVE-2024-21177](https://nvd.nist.gov/vuln/detail/CVE-2024-21177)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240529
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240529 est désormais disponible.
**Bugs corrigés :**
+ Correction d’un échec d’assertion `field.cc` en implémentant `fix_after_pullout`.
+ Correction d’une défaillance du pointeur nul lors du renvoi des métadonnées au client pour certaines requêtes SQL. Ces requêtes contenaient des paramètres dynamiques et des sous-requêtes dans des clauses `SELECT`.
+ Correction de résultats incorrects lors de l’utilisation de `GROUP BY` pour des scans d’index faibles ou des scans de plages non contiguës d’un index.
+ Correction de la perte d’informations GTID en cas de crash de MySQL pendant la persistance.
+ Correction d’une condition de course qui pouvait entraîner le blocage indéfini d’une transaction InnoDB.
+ Correction d’une condition de course lors du nettoyage des informations de certification par la réplication de groupe.
+ Correction d’un problème de scan de l’index descendant avec des opérations de page simultanées.
+ Correction d’un problème d’incohérence de l’état de recherche en texte intégral (FTS) dans des scénarios concurrents.
+ Correction d’un problème d’assertion lié à la mémoire tampon de modification lors de la suppression de tables.
+ Comportement unifié pour l’appel de la fonction `deinit` pour tous les types de plugins.
**CVEs fixe :**
+ [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963)
+ [CVE-2024-20993](https://nvd.nist.gov/vuln/detail/CVE-2024-20993)
+ [CVE-2024-20998](https://nvd.nist.gov/vuln/detail/CVE-2024-20998)
+ [CVE-2024-21009](https://nvd.nist.gov/vuln/detail/CVE-2024-21009)
+ [CVE-2024-21054](https://nvd.nist.gov/vuln/detail/CVE-2024-21054)
+ [CVE-2024-21055](https://nvd.nist.gov/vuln/detail/CVE-2024-21055)
+ [CVE-2024-21057](https://nvd.nist.gov/vuln/detail/CVE-2024-21057)
+ [CVE-2024-21062](https://nvd.nist.gov/vuln/detail/CVE-2024-21062)
+ [CVE-2024-21008](https://nvd.nist.gov/vuln/detail/CVE-2024-21008)
+ [CVE-2024-21013](https://nvd.nist.gov/vuln/detail/CVE-2024-21013)
+ [CVE-2024-21047](https://nvd.nist.gov/vuln/detail/CVE-2024-21047)
+ [CVE-2024-21087](https://nvd.nist.gov/vuln/detail/CVE-2024-21087)
+ [CVE-2024-21096](https://nvd.nist.gov/vuln/detail/CVE-2024-21096)
### Support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240408
Le support étendu RDS pour RDS for MySQL version 5.7.44-RDS.20240408 est désormais disponible.
Cette version contient des correctifs pour les éléments suivants CVEs :
+ [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963)
## Utilisation de l’environnement de version préliminaire de base de données
En juillet 2023, Oracle a annoncé un nouveau modèle de version pour MySQL. Ce modèle inclut deux types de versions : les versions Innovation et les versions LTS. Amazon RDS met à disposition les versions Innovation de MySQL dans l'environnement de prévisualisation RDS. Pour en savoir plus sur les versions Innovation de MySQL, consultez le blog [Introducing MySQL Innovation and Long-Term Support (LTS) versions](https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions).
Les instances de base de données RDS for MySQL dans l’environnement de version préliminaire de base de données sont similaires sur le plan fonctionnel à d’autres instances de base de données RDS for MySQL. Cependant, vous ne pouvez pas utiliser l’environnement de version préliminaire de base de données pour les charges de travail de production.
Les environnements de prévisualisation présentent les limitations suivantes :
+ Amazon RDS supprime toutes les instances de base de données 60 jours après leur création, en même temps que leurs sauvegardes et leurs instantanés.
+ Vous ne pouvez utiliser que les stockages SSD à usage général et les stockages SSD à IOPS provisionnées.
+ Vous ne pouvez pas obtenir d'aide Support avec les instances de base de données. [Vous pouvez plutôt publier vos questions sur la communauté de AWS questions-réponses gérée,AWS Re:post.](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service)
+ Vous ne pouvez pas copier un instantané d’instance de base de données dans un environnement de production.
Les options suivantes sont prises en charge par la prévisualisation.
+ Vous pouvez créer des instances de base de données à l'aide des classes d'instance de base de données db.m6i, db.r6i, db.m6g, db.m5, db.t3, db.r6g et db.r5. Pour plus d’informations sur les classes d’instance RDS, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
+ Vous pouvez utiliser à la fois des déploiements mono-AZ et multi-AZ.
+ Vous pouvez utiliser les fonctions de vidage et de chargement MySQL standard pour exporter des bases de données depuis l’environnement de version préliminaire de base de données ou pour importer des bases de données dans cet environnement.
### Fonctions non prises en charge dans l’environnement de version préliminaire de base de données
Les fonctions suivantes ne sont pas disponibles dans l’environnement de version préliminaire de base de données :
+ Copie d’instantanés entre Régions
+ Réplicas en lecture entre Régions
+ RDS Proxy (Proxy RDS)
### Création d’une nouvelle instance de base de données dans l’environnement de version préliminaire de base de données
Vous pouvez créer une instance de base de données dans l'environnement Database Preview à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
#### Console
**Pour créer une instance de base de données dans l’environnement de version préliminaire de base de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Choisissez **Dashboard (Tableau de bord)** dans le panneau de navigation.
1. Sur la page **Tableau de bord**, recherchez la section **Environnement de version préliminaire de base de données**, comme illustré dans l’image suivante.
![\[La section Environnement de version préliminaire de base de données avec lien dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
Vous pouvez accéder directement à l’[environnement de version préliminaire de base de données](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#). Avant de poursuivre, vous devez reconnaître et accepter les limites.
![\[La boîte de dialogue Accord de service pour l’environnement de version préliminaire de base de données pour confirmer les limites.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. Pour créer l’instance de base de données RDS for MySQL, suivez le même processus que pour créer n’importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### AWS CLI
Pour créer une instance de base de données dans l’environnement de version préliminaire de base de données à l’aide de l’ AWS CLI, utilisez le point de terminaison suivant.
```
rds-preview.us-east-2.amazonaws.com
```
Pour créer l'instance de base de données RDS for MySQL, suivez le même processus que pour créer n'importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
#### API RDS
Pour créer une instance de base de données dans l’environnement de version préliminaire de base de données à l’aide de l’API RDS, utilisez le point de terminaison suivant.
```
rds-preview.us-east-2.amazonaws.com
```
Pour créer l'instance de base de données RDS for MySQL, suivez le même processus que pour créer n'importe quelle instance de base de données Amazon RDS. Pour plus d’informations, consultez la procédure [API RDS](USER_CreateDBInstance.md#USER_CreateDBInstance.API) dans [Création d’une instance de base de données](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating).
## MySQL version 9.5 dans l'environnement Database Preview
MySQL version 9.5 est désormais disponible dans l'environnement Amazon RDS Database Preview. La version 9.5 de MySQL contient plusieurs améliorations décrites dans [Modifications apportées à MySQL 9.5.0](https://dev.mysql.com/doc/relnotes/mysql/9.5/en/news-9-5-0.html).
Pour plus d’informations sur l’environnement de version préliminaire de base de données, consultez [Utilisation de l’environnement de version préliminaire de base de données](#mysql-working-with-the-database-preview-environment). Pour accéder à l'environnement de prévisualisation depuis la console, sélectionnez [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
## MySQL version 9.4 dans l'environnement Database Preview
MySQL version 9.4 est désormais disponible dans l'environnement Amazon RDS Database Preview. La version 9.4 de MySQL contient plusieurs améliorations décrites dans [Modifications apportées à MySQL 9.4.0](https://dev.mysql.com/doc/relnotes/mysql/9.4/en/news-9-4-0.html).
Pour plus d’informations sur l’environnement de version préliminaire de base de données, consultez [Utilisation de l’environnement de version préliminaire de base de données](#mysql-working-with-the-database-preview-environment). Pour accéder à l'environnement de prévisualisation depuis la console, sélectionnez [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
## MySQL version 9.3 dans l’environnement de version préliminaire de base de données
MySQL version 9.3 est désormais disponible dans l'environnement Amazon RDS Database Preview. MySQL version 9.3 contient plusieurs améliorations qui sont décrites dans [Changements dans MySQL 9.3.0.](https://dev.mysql.com/doc/relnotes/mysql/9.3/en/news-9-3-0.html)
Pour plus d’informations sur l’environnement de version préliminaire de base de données, consultez [Utilisation de l’environnement de version préliminaire de base de données](#mysql-working-with-the-database-preview-environment). Pour accéder à l'environnement de prévisualisation depuis la console, sélectionnez [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/).
## Versions rendues obsolètes pour Amazon RDS for MySQL
Les versions Amazon RDS for MySQL 5.1, 5.5 et 5.6 sont rendues obsolètes.
Les versions 9.1 et 9.2 d'Amazon RDS for MySQL sont obsolètes dans l'environnement Database Preview.
[Pour plus d'informations sur la politique d'obsolescence d'Amazon RDS pour MySQL, consultez Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/)
# Connexion à votre instance de base de données MySQL
Avant de vous connecter à une instance de base de données qui exécute le moteur de base de données MySQL, vous devez créer une instance de base de données. Pour plus d'informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md). Après qu'Amazon RDS a provisionné votre instance de base de données, vous pouvez utiliser n'importe quelle application cliente MySQL standard pour vous connecter à l'instance. Dans la chaîne de connexion, vous spécifiez l'adresse DNS du point de terminaison de l'instance de base de données comme paramètre de l'hôte, et le numéro de port du point de terminaison de l'instance de base de données comme paramètre du port.
Pour vous authentifier sur votre instance de base de données RDS, vous pouvez utiliser l'une des méthodes d'authentification pour MySQL et l'authentification de base de données Gestion des identités et des accès AWS (IAM).
+ Pour en savoir plus sur l'authentification sur MySQL à l'aide de l'une des méthodes d'authentification pour MySQL, consultez [ Méthode d'authentification](https://dev.mysql.com/doc/internals/en/authentication-method.html) dans la documentation MySQL.
+ Pour en savoir plus sur l'authentification sur MySQL à l'aide de l'authentification de base de données IAM, consultez [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
Vous pouvez vous connecter à une instance de base de données MySQL en utilisant des outils tels que le client de ligne de commande MySQL. Pour plus d'informations sur l'utilisation du client de ligne de commande MySQL, consultez [mysql - Le client de ligne de commande MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) dans la documentation MySQL. MySQL Workbench est une application basée sur l'interface utilisateur graphique que vous pouvez utiliser pour la connexion. Pour plus d'informations, consultez la page [Download MySQL Workbench](http://dev.mysql.com/downloads/workbench/). Pour plus d'informations sur l'installation de MySQL (y compris le client de ligne de commande MySQL), consultez [Installation et mise à niveau de MySQL](https://dev.mysql.com/doc/refman/8.0/en/installing.html).
Pour se connecter à une instance de base de données hors de son Amazon VPC, l'instance de base de données doit être accessible au public, l'accès doit être accordé en utilisant les règles entrantes du groupe de sécurité de l'instance de base de données et d'autres exigences doivent être respectées. Pour plus d’informations, consultez [Impossible de se connecter à l’instance de base de données Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
Vous pouvez utiliser le chiffrement Secure Sockets Layer (SSL) ou Transport Layer Security (TLS) pour les connexions à une instance de base de données MySQL. Pour plus d’informations, consultez [Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS](MySQL.Concepts.SSLSupport.md). Si vous utilisez l'authentification de base de données Gestion des identités et des accès AWS (IAM), veillez à utiliser une connexion SSL/TLS. Pour plus d’informations, consultez [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
Vous pouvez également vous connecter à une instance de base de données à partir d'un serveur Web. Pour plus d'informations, consultez [Didacticiel : Créer un serveur web et une instance de base de données Amazon RDS](TUT_WebAppWithRDS.md).
**Note**
Pour plus d’informations sur la connexion à une instance de base de données MariaDB, consultez [Connexion à votre instance de base de données MariaDB](USER_ConnectToMariaDBInstance.md).
Pour rechercher et vous connecter à une instance de base de données RDS for MySQL, consultez les rubriques suivantes.
**Topics**
+ [
# Recherche des informations de connexion pour une instance de base de données RDS for MySQL
](USER_ConnectToInstance.EndpointAndPort.md)
+ [
# Installation du client de ligne de commande MySQL
](mysql-install-cli.md)
+ [
# Connexion à partir du client de ligne de commande MySQL (non chiffrée)
](USER_ConnectToInstance.CLI.md)
+ [
# Connexion depuis MySQL Workbench
](USER_ConnectToInstance.MySQLWorkbench.md)
+ [
# Connexion à RDS pour MySQL avec le pilote AWS JDBC, le pilote AWS Python et le pilote AWS ODBC pour MySQL
](MySQL.Connecting.Drivers.md)
+ [
# Dépannage des connexions à votre instance de base de données MySQL
](USER_ConnectToInstance.Troubleshooting.md)
# Recherche des informations de connexion pour une instance de base de données RDS for MySQL
Les informations de connexion d’une instance de base de données incluent son point de terminaison, son port et un utilisateur de base de données valide, tel que l’utilisateur principal. Par exemple, supposons qu'une valeur de point de terminaison soit `mydb.123456789012.us-east-1.rds.amazonaws.com`. Dans ce cas, la valeur du port est `3306`, et l'utilisateur de base de données est `admin`. Compte tenu de ces informations, vous spécifiez les valeurs suivantes dans une chaîne de connexion :
+ Pour un hôte, un nom d'hôte ou un nom DNS, spécifiez `mydb.123456789012.us-east-1.rds.amazonaws.com`.
+ Pour un port, spécifiez `3306`.
+ Pour l'utilisateur, spécifiez `admin`.
Pour vous connecter à une instance de base de données, utilisez n'importe quel client pour le moteur de base de données MySQL. Par exemple, vous pourriez utiliser le client de ligne de commande MySQL ou MySQL Workbench.
Pour trouver les informations de connexion d'une instance de base de données, vous pouvez utiliser la AWS Management Console AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande ou l'DBInstancesopération Amazon RDS API [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) pour répertorier ses détails.
## Console
**Pour trouver les informations de connexion d'une instance de base de données dans AWS Management Console**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Bases de données** pour afficher la liste de vos instances de base de données.
1. Choisissez le nom de l'instance de base de données MySQL pour afficher ses détails.
1. Dans l'onglet **Connectivity & security (Connectivité et sécurité)**, copiez le point de terminaison. Notez également le numéro du port. Vous avez besoin du point de terminaison et du numéro de port pour vous connecter à l'instance de base de données.
![\[Point de terminaison et port d’une instance de base de données dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/endpoint-port.png)
1. Si vous devez rechercher le nom d’utilisateur principal, choisissez l’onglet **Configuration** et affichez la valeur **Master username (Identifiant principal**.
## AWS CLI
Pour trouver les informations de connexion d'une instance de base de données MySQL à l'aide de AWS CLI, exécutez la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande. Dans l’appel, recherchez l’ID d’instance de base de données, le point de terminaison, le port et l’identifiant principal.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-instances \
--filters "Name=engine,Values=mysql" \
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Pour Windows :
```
aws rds describe-db-instances ^
--filters "Name=engine,Values=mysql" ^
--query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]"
```
Votre sortie doit ressembler à ce qui suit.
```
[
[
"mydb1",
"mydb1.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
],
[
"mydb2",
"mydb2.123456789012.us-east-1.rds.amazonaws.com",
3306,
"admin"
]
]
```
## API RDS
Pour trouver les informations de connexion d'une instance de base de données à l'aide de l'API Amazon RDS, appelez l'DBInstancesopération [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). Dans la sortie, recherchez les valeurs de l’adresse du point de terminaison, du port du point de terminaison et du nom d’utilisateur principal.
# Installation du client de ligne de commande MySQL
La plupart des distributions Linux incluent le client MariaDB au lieu du client MySQL Oracle. Pour installer le client de ligne de commande MySQL sur Amazon Linux 2023, exécutez la commande suivante :
```
sudo dnf install mariadb105
```
Pour installer le client de ligne de commande MySQL sur Amazon Linux 2, exécutez la commande suivante :
```
sudo yum install mariadb
```
Pour installer le client de ligne de commande MySQL sur la plupart des distributions Linux basées sur DEB, exécutez la commande suivante :
```
apt-get install mariadb-client
```
Pour vérifier la version de votre client de ligne de commande MySQL, exécutez la commande suivante :
```
mysql --version
```
Pour lire la documentation MySQL pour votre version de client actuelle, exécutez la commande suivante :
```
man mysql
```
# Connexion à partir du client de ligne de commande MySQL (non chiffrée)
**Important**
N’utilisez une connexion MySQL non chiffrée que quand le client et le serveur sont dans le même VPC et que le réseau est approuvé. Pour plus d’informations sur l’utilisation de connexions chiffrées, consultez [Connexion à votre instance de base de données MySQL sur Amazon RDS SSL/TLS depuis le client de ligne de commande MySQL (crypté)](USER_ConnectToInstanceSSL.CLI.md).
Pour vous connecter à une instance de base de données à l'aide du client de ligne de commande MySQL, entrez la commande suivante à l'invite de commandes d'un ordinateur client. Pour le paramètre -h, remplacez le nom DNS (point de terminaison) de votre instance de base de données. Pour le paramètre -P, remplacez le port pour votre instance de base de données. Pour le paramètre -u, remplacez le nom d'utilisateur d'un utilisateur de base de données valide, par exemple l'utilisateur principal. Entrez le mot de passe de l'utilisateur principal quand vous y êtes invité.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com -P 3306 -u mymasteruser -p
```
Après avoir entré le mot de passe pour l’utilisateur, le résultat suivant devrait normalement s’afficher.
```
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 9738
Server version: 8.0.28 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
```
# Connexion depuis MySQL Workbench
**Pour se connecter depuis MySQL Workbench**
1. Téléchargez et installez MySQL Workbench depuis [Télécharger MySQL Workbench](http://dev.mysql.com/downloads/workbench/).
1. Ouvrez MySQL Workbench.
![\[L’écran de bienvenue dans MySQL Workbench.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/mysql-workbench-main.png)
1. Dans **Base de données**, choisissez **Gérer les connexions**.
1. Dans la fenêtre **Gérer les connexions du serveur**, choisissez **Nouveau**.
1. Dans la fenêtre **Se connecter à la base de données**, entrez les informations suivantes :
+ **Connexion stockée** – Entrez un nom pour la connexion, par exemple **MyDB**.
+ **Nom d'hôte** – Entrez le point de terminaison de l'instance de base de données.
+ **Port** – Entrez le port utilisé par l'instance de base de données.
+ **Nom d'utilisateur** – Entrez le nom d'utilisateur d'un utilisateur de base de données valide, par exemple l'utilisateur principal.
+ **Mot de passe** – Facultatif. Choisissez **Stocker dans le coffre**, puis entrez et enregistrez le mot de passe de l'utilisateur.
La fenêtre ressemble à ce qui suit :
![\[La fenêtre Gérer les connexions de serveur dans MySQL Workbench.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/mysql-workbench-connect.png)
Vous pouvez utiliser les fonctionnalités de MySQL Workbench pour personnaliser les connexions. Par exemple, vous pouvez utiliser l'onglet **SSL** pour configurer les connexions SSL/TLS. Pour plus d’informations sur l’utilisation de MySQL Workbench, consultez le manuel [MySQL Workbench](https://dev.mysql.com/doc/workbench/en/). Pour plus d'informations sur le chiffrement des connexions client aux instances de base de données MySQL avec SSL/TLS, consultez [Chiffrement des connexions client avec les instances SSL/TLS de base de données MySQL sur Amazon RDS](mysql-ssl-connections.md).
1. Facultatif. Vous pouvez choisir **Tester la connexion** pour vous assurer que la connexion à l'instance de base de données est réussie.
1. Choisissez **Fermer**.
1. Dans **Base de données**, choisissez **Se connecter à la base de données**.
1. Dans **Connexion stockée**, choisissez votre connexion.
1. Choisissez **OK**.
# Connexion à RDS pour MySQL avec le pilote AWS JDBC, le pilote AWS Python et le pilote AWS ODBC pour MySQL
Connectez-vous aux instances de base de données RDS pour MySQL à l'aide du pilote AWS JDBC, du pilote AWS Python et du AWS pilote ODBC pour MySQL. Pour plus d’informations, consultez les rubriques suivantes.
**Topics**
+ [
## Connexion à RDS for MySQL avec le pilote JDBC Amazon Web Services (AWS)
](#MySQL.Connecting.JDBCDriver)
+ [
## Connexion à RDS for MySQL avec le pilote Python Amazon Web Services (AWS)
](#MySQL.Connecting.PythonDriver)
+ [
## Connexion à RDS for MySQL avec le pilote ODBC Amazon Web Services (AWS) pour MySQL
](#USER_ConnectToInstance.ODBCDriverMySQL)
## Connexion à RDS for MySQL avec le pilote JDBC Amazon Web Services (AWS)
Le pilote JDBC Amazon Web Services (AWS) est conçu comme un wrapper JDBC avancé. Ce wrapper complète et étend les fonctionnalités d’un pilote JDBC existant. Le pilote est compatible directement avec le Connector/J pilote MySQL communautaire et le pilote communautaire MariaDB Connector/J .
Pour installer le pilote AWS JDBC, ajoutez le fichier .jar du pilote AWS JDBC (situé dans l'application`CLASSPATH`) et conservez les références au pilote communautaire correspondant. Mettez à jour le préfixe d’URL de connexion correspondant comme suit :
+ `jdbc:mysql://` sur `jdbc:aws-wrapper:mysql://`
+ `jdbc:mariadb://` sur `jdbc:aws-wrapper:mariadb://`
Pour plus d'informations sur le pilote AWS JDBC et des instructions complètes pour son utilisation, consultez le référentiel de pilotes [JDBC Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub
## Connexion à RDS for MySQL avec le pilote Python Amazon Web Services (AWS)
Le pilote Python Amazon Web Services (AWS) est conçu comme un wrapper Python avancé. Ce wrapper complète et étend les fonctionnalités du pilote open source Psycopg. Le pilote AWS Python prend en charge les versions 3.8 et ultérieures de Python. Vous pouvez installer le package `aws-advanced-python-wrapper` à l’aide de la commande `pip`, en même temps que les packages `psycopg` open source.
Pour plus d'informations sur le pilote AWS Python et des instructions complètes pour son utilisation, consultez le [ GitHub référentiel de pilotes Python Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-python-wrapper).
## Connexion à RDS for MySQL avec le pilote ODBC Amazon Web Services (AWS) pour MySQL
Le pilote AWS ODBC pour MySQL est un pilote client conçu pour la haute disponibilité de RDS pour MySQL. Le pilote peut coexister avec le Connector/ODBC pilote MySQL et est compatible avec les mêmes flux de travail.
Pour plus d'informations sur le pilote AWS ODBC pour MySQL et des instructions complètes pour son installation et son utilisation, consultez le référentiel du [pilote ODBC pour MySQL GitHub d'Amazon Web Services (AWS)](https://github.com/aws/aws-mysql-odbc).
# Dépannage des connexions à votre instance de base de données MySQL
Les deux causes les plus courantes d'échec de connexion à une nouvelle instance de base de données sont :
+ L'instance de base de données a été créée grâce à un groupe de sécurité qui interdit les connexions depuis l'appareil ou l'instance Amazon EC2 où l'application ou l'utilitaire MySQL s'exécute. L'instance de base de données doit avoir un groupe de sécurité VPC qui autorise les connexions. Pour de plus amples informations, veuillez consulter [Amazon VPC et Amazon RDS](USER_VPC.md).
Vous pouvez ajouter ou modifier une règle entrante dans le groupe de sécurité. Pour **Source**, choisissez **Mon IP**. Cela autorise à accéder à l'instance de base de données à partir de l'adresse IP détectée dans votre navigateur.
+ L'instance de base de données a été créée à l'aide du port par défaut 3306, et votre entreprise dispose de règles de pare-feu bloquant les connexions à ce port depuis les appareils de votre réseau d'entreprise. Pour corriger le problème, recréez l'instance avec un port différent.
Pour plus d’informations sur les problèmes de connexion, consultez [Impossible de se connecter à l’instance de base de données Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
# Sécurisation des connexions d'instance de base de données MySQL
Vous pouvez mettre en œuvre des mesures de sécurité robustes pour protéger les instances de base de données MySQL contre les accès non autorisés et les menaces potentielles. Les groupes de sécurité, le chiffrement SSL/TLS et l’authentification de base de données IAM fonctionnent ensemble pour créer plusieurs niveaux de sécurité de connexion pour vos instances de base de données MySQL. Ces contrôles de sécurité vous aident à respecter les exigences de conformité, à prévenir les violations de données et à maintenir des canaux de communication sécurisés entre les applications et les bases de données. Vous pouvez sécuriser vos instances de base de données MySQL en chiffrant les données en transit, en limitant l’accès à des plages d’adresses IP spécifiques et en gérant l’authentification des utilisateurs via des rôles IAM plutôt que des mots de passe de base de données.
La sécurité des instances de bases de données MySQL est gérée à trois niveaux :
+ Gestion des identités et des accès AWS contrôle les personnes autorisées à exécuter des actions de gestion Amazon RDS sur des instances de base de données. Lorsque vous vous connectez à AWS en utilisant les informations d'identification IAM, votre compte IAM doit disposer des stratégies IAM qui accordent les autorisations requises pour exécuter les opérations de gestion d'Amazon RDS. Pour plus d’informations, consultez [Identity and Access Management pour Amazon RDS](UsingWithRDS.IAM.md).
+ Lorsque vous créez une instance de base de données, vous utilisez un groupe de sécurité VPC pour contrôler les appareils et les instances Amazon EC2 qui peuvent ouvrir des connexions au point de terminaison et au port de l'instance de base de données. Ces connexions peuvent être établies en utilisant le protocole SSL (Secure Sockets Layer) et le protocole TLS (Transport Layer Security). En outre, les règles de pare-feu de votre entreprise peuvent contrôler si les appareils en cours d’exécution dans votre entreprise peuvent ouvrir des connexions à l’instance de base de données.
+ Pour authentifier la connexion et les autorisations d’une instance de base de données MySQL, vous pouvez adopter l’une des approches suivantes, ou les combiner.
+ Vous pouvez adopter la même approche qu'avec une instance autonome de MySQL. Les commandes telles que `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` et `SET PASSWORD` fonctionnent de la même façon que dans les bases de données sur site, comme le fait la modification directe des tables du schéma de base de données. Cependant, la modification directe des tables du schéma de base de données n’est pas une bonne pratique, et elle n’est plus prise en charge à partir de la version 8.0.36 de RDS for MySQL. Pour plus d’informations, consultez [Access Control and Account Management](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) dans la documentation MySQL.
+ Vous pouvez également utiliser l'authentification de base de données IAM. L'authentification de base de données IAM vous permet de vous authentifier sur votre instance de base de données à l'aide d'un utilisateur IAM ou d'un rôle IAM et d'un jeton d'authentification. Un *jeton d'authentification* est une valeur unique qui est générée à l'aide du processus de signature Signature Version 4. L'authentification de base de données IAM vous permet d'utiliser les mêmes informations d'identification pour contrôler l'accès à vos ressources AWS et à vos bases de données. Pour plus d’informations, consultez [Authentification de base de données IAMpour MariaDB, MySQL et PostgreSQL](UsingWithRDS.IAMDBAuth.md).
+ Vous pouvez également utiliser l'authentification Kerberos pour RDS for MySQL. L’instance de base de données fonctionne avec AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) pour permettre l’authentification Kerberos. Lorsque les utilisateurs s'authentifient avec une instance de base de données MySQL jointe au domaine d'approbation, les demandes d'authentification sont transférées. Les demandes transférées vont dans l’annuaire de domaine que vous créez avec Directory Service. Pour plus d’informations, consultez [Utilisation de l’authentification Kerberos pour Amazon RDS for MySQL](mysql-kerberos.md).
Lorsque vous créez une instance de base de données Amazon RDS, l’utilisateur principal a les privilèges par défaut suivants :
| Version de moteur | Privilège système | Rôle de base de données |
| --- | --- | --- |
| RDS for MySQL versions 8.4.3 ultérieures | `GRANT SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`,`INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `FLUSH_OPTIMIZER_COSTS`, `FLUSH_PRIVILEGES`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`, `ROLE_ADMIN`, `SENSITIVE_VARIABLES_OBSERVER`, `SESSION_VARIABLES_ADMIN`, `SET_ANY_DEFINER`, `SHOW_ROUTINE`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Pour plus d’informations sur `rds_superuser_role`, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). |
| RDS for MySQL versions 8.0.36 ultérieures | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `ROLE_ADMIN`, `SET_USER_ID`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Pour plus d’informations sur `rds_superuser_role`, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). |
| RDS for MySQL versions inférieures à 8.0.36 | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `REPLICATION SLAVE` | Aucun |
**Note**
Bien qu'il soit possible de supprimer l'utilisateur maître sur l'instance de base de données, il n'est pas recommandé de le faire. Pour recréer l’utilisateur maître, utilisez l’opération d’API RDS [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) ou exécutez la commande d’AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) et spécifiez un nouveau mot de passe d’identifiant principal avec le paramètre approprié. Si l’utilisateur maître n’existe pas dans l’instance, il est créé avec le mot de passe spécifié.
Pour fournir des services de gestion à chaque instance de base de données, l'utilisateur `rdsadmin` est créé lors de la création de l'instance de base de données. Les tentatives de supprimer, renommer et modifier le mot de passe du compte `rdsadmin`, ou d'en modifier les privilèges, génèrent une erreur.
Pour autoriser la gestion de l'instance de base de données, les commandes standard `kill` et `kill_query` ont fait l'objet de restrictions. Les commandes Amazon RDS `rds_kill` et `rds_kill_query` sont fournies pour vous permettre de mettre fin aux requêtes ou aux sessions utilisateur sur les instances de base de données.
# Validation de mot de passe pour RDS for MySQL
MySQL fournit le plug-in `validate_password` pour assurer une sécurité améliorée. Le plug-in applique des stratégies de mot de passe à l'aide de paramètres du groupe de paramètres de base de données pour votre instance de base de données MySQL. Le plugin est pris en charge pour les instances de base de données exécutant MySQL version 5.7, 8.0 et 8.4. Pour plus d’informations sur le plug-in `validate_password`, consultez [Plug-in de validation de mot de passe](https://dev.mysql.com/doc/refman/5.7/en/validate-password.html) dans la documentation MySQL.
**Pour activer le plugin `validate_password` pour une instance de base de données MySQL**
1. Connectez-vous à votre instance de base de données MySQL et exécutez la commande suivante.
```
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
```
1. Configurez les paramètres du plug-in dans le groupe de paramètres de base de données utilisé par l'instance de base de données.
Pour plus d’informations sur les paramètres, consultez [Password Validation Plugin Options and Variables](https://dev.mysql.com/doc/refman/5.7/en/validate-password-options-variables.html) dans la documentation MySQL.
Pour plus d'informations sur la modification des paramètres d'instance de base de données, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Redémarrez l’instance de base de données.
Après avoir activé le plugin `validate_password`, réinitialisez les mots de passe existants conformément à vos nouvelles stratégies de validation.
Votre instance de base de données MySQL gère la validation du mot de passe pour Amazon RDS. Pour modifier un mot de passe, vous devez d'abord envoyer une demande de mise à jour du mot de passe par le biais de la console de gestion AWS, de la commande `modify-db-instance` CLI ou de `ModifyDBInstance` l'opération API. RDS accepte initialement votre demande, même si le mot de passe ne correspond pas à vos politiques. RDS traite ensuite la demande de manière asynchrone. Il met à jour le mot de passe dans votre instance de base de données MySQL uniquement s'il répond aux politiques que vous avez définies. Si le mot de passe ne respecte pas ces règles, RDS conserve le mot de passe existant et enregistre un événement d'erreur.
```
Unable to reset your password. Error information: Password failed to meet validation rules.
```
Pour plus d’informations sur les événements Amazon RDS, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
# Chiffrement des connexions client avec les instances SSL/TLS de base de données MySQL sur Amazon RDS
Secure Sockets Layer (SSL) est un protocole de norme industrielle utilisé pour sécuriser les connexions réseau entre client et serveur. Après la version 3.0 de SSL, le nom du protocole est devenu Transport Layer Security (TLS). Amazon RDS prend en charge le SSL/TLS chiffrement pour les instances de base de données MySQL. L'utilisation SSL/TLS, you can encrypt a connection between your application client and your MySQL DB instance. SSL/TLS du support est disponible dans tous les domaines Régions AWS pour MySQL.
Avec Amazon RDS, vous pouvez sécuriser les données en transit en chiffrant les connexions client aux instances de base de données MySQL et en SSL/TLS, requiring SSL/TLS for all connections to a MySQL DB instance, and connecting from the MySQL command-line client with SSL/TLS (encrypted). The following sections provide guidance on configuring and utilizing SSL/TLS chiffrant les instances de base de données MySQL sur Amazon RDS.
**Topics**
+ [
# Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS
](MySQL.Concepts.SSLSupport.md)
+ [
# Exiger des comptes utilisateur spécifiques SSL/TLS pour une instance de base de données MySQL sur Amazon RDS
](mysql-ssl-connections.require-ssl-users.md)
+ [
# Exiger toutes SSL/TLS les connexions à une instance de base de données MySQL sur Amazon RDS
](mysql-ssl-connections.require-ssl.md)
+ [
# Connexion à votre instance de base de données MySQL sur Amazon RDS SSL/TLS depuis le client de ligne de commande MySQL (crypté)
](USER_ConnectToInstanceSSL.CLI.md)
# Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS
Amazon RDS crée un SSL/TLS certificat et l'installe sur l'instance de base de données lorsqu'Amazon RDS approvisionne l'instance. Ces certificats sont signés par une autorité de certification. Le SSL/TLS certificat inclut le point de terminaison de l'instance de base de données comme nom commun (CN) du SSL/TLS certificat afin de se prémunir contre les attaques par usurpation d'identité.
Un SSL/TLS certificat créé par Amazon RDS est l'entité racine fiable et devrait fonctionner dans la plupart des cas, mais il peut échouer si votre application n'accepte pas les chaînes de certificats. Si votre application ne les accepte pas, vous devrez peut-être utiliser un certificat intermédiaire pour vous connecter à votre Région AWS. Par exemple, vous devez utiliser un certificat intermédiaire pour vous connecter aux AWS GovCloud (US) régions avec SSL/TLS.
Pour plus d’informations sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md). Pour plus d'informations sur l'utilisation SSL/TLS de MySQL, consultez[Mise à jour des applications pour se connecter aux instances de base de données MySQL à l'aide de nouveaux SSL/TLS certificats](ssl-certificate-rotation-mysql.md).
Pour MySQL versions 8.0 et antérieures, Amazon RDS for MySQL utilise OpenSSL pour sécuriser les connexions. Pour MySQL versions 8.4 et ultérieures, Amazon RDS for MySQL utilise AWS-LC. La prise en charge du protocole TLS dépend de la version de MySQL. Le tableau suivant affiche la prise en charge du protocole TLS pour les versions MySQL.
| Version MySQL | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
| --- | --- | --- | --- | --- |
| MySQL 8.4 | Non pris en charge | Non pris en charge | Pris en charge | Pris en charge |
| MySQL 8.0 | Non pris en charge | Non pris en charge | Pris en charge | Pris en charge |
| MySQL 5.7 | Pris en charge | Pris en charge | Pris en charge | Non pris en charge |
# Exiger des comptes utilisateur spécifiques SSL/TLS pour une instance de base de données MySQL sur Amazon RDS
Vous pouvez exiger SSL/TLS le chiffrement pour les connexions de comptes utilisateur spécifiques à vos instances de base de données MySQL sur Amazon RDS. La protection des informations sensibles contre tout accès non autorisé ou toute interception est essentielle pour appliquer les politiques de sécurité, lorsque la confidentialité des données est une préoccupation.
Pour exiger des SSL/TLS connexions pour des comptes d'utilisateurs spécifiques, utilisez l'une des instructions suivantes, en fonction de votre version de MySQL, pour exiger SSL/TLS des connexions sur le compte utilisateur`encrypted_user`.
Pour cela, utilisez l’instruction suivante.
```
ALTER USER 'encrypted_user'@'%' REQUIRE SSL;
```
Pour plus d'informations sur SSL/TLS les connexions avec MySQL, consultez la section [Utilisation de connexions chiffrées](https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html) dans la documentation MySQL.
# Exiger toutes SSL/TLS les connexions à une instance de base de données MySQL sur Amazon RDS
Utilisez le paramètre `require_secure_transport` pour exiger que toutes les connexions des utilisateurs à votre instance de base de données MySQL utilisent SSL/TLS. Par défaut, le paramètre `require_secure_transport` est défini sur `OFF`. Vous pouvez définir le `require_secure_transport` paramètre sur « require `ON` » SSL/TLS pour les connexions à votre instance de base de données.
Vous pouvez définir la valeur du paramètre `require_secure_transport` en mettant à jour le groupe de paramètres de base de données pour votre instance de base de données. Vous n'avez pas besoin de redémarrer votre instance de base de données pour que la modification prenne effet.
Lorsque le paramètre `require_secure_transport` est défini sur `ON` pour une instance de base de données, un client de base de données peut s'y connecter s'il peut établir une connexion chiffrée. Sinon, un message d’erreur similaire au suivant est renvoyé au client :
```
MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.
```
Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
Pour obtenir plus d'informations sur le paramètre `require_secure_transport`, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_require_secure_transport).
# Connexion à votre instance de base de données MySQL sur Amazon RDS SSL/TLS depuis le client de ligne de commande MySQL (crypté)
Les paramètres du programme client `mysql` sont légèrement différents selon la version de MySQL ou de MariaDB que vous utilisez.
Pour savoir quelle version vous avez, exécutez la commande `mysql` avec l'option `--version`. Dans l'exemple suivant, la sortie indique que le programme client provient de MariaDB.
```
$ mysql --version
mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1
```
La plupart des distributions Linux, telles qu'Amazon Linux, CentOS, SUSE et Debian, ont remplacé MySQL par MariaDB, et la version de `mysql` qu'elles contiennent provient de MariaDB.
Pour vous connecter à votre instance de base de données en utilisant SSL/TLS, procédez comme suit :
**Pour vous connecter à une instance de base de données à SSL/TLS l'aide du client de ligne de commande MySQL**
1. Téléchargez un certificat racine qui fonctionne pour tous Régions AWS.
Pour plus d’informations sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md).
1. Utilisez un client de ligne de commande MySQL pour vous connecter à une instance de base de données avec chiffrement SSL/TLS. Pour le paramètre `-h`, remplacez le nom DNS (point de terminaison) de votre instance de base de données. Remplacez le `--ssl-ca` paramètre par le nom du fichier de SSL/TLS certificat. Pour le paramètre `-P`, remplacez le port pour votre instance de base de données. Pour le paramètre `-u`, remplacez le nom d'utilisateur d'un utilisateur de base de données valide, par exemple l'utilisateur principal. Entrez le mot de passe de l'utilisateur principal quand vous y êtes invité.
L'exemple suivant montre comment lancer le client à l'aide du paramètre `--ssl-ca` en utilisant le client MySQL 5.7 ou version ultérieure.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p
```
Pour exiger que la SSL/TLS connexion vérifie le point de terminaison de l'instance de base de données par rapport au point de terminaison indiqué dans le SSL/TLS certificat, entrez la commande suivante :
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=VERIFY_IDENTITY -P 3306 -u myadmin -p
```
L'exemple suivant montre comment lancer le client à l'aide du paramètre `--ssl-ca` en utilisant le client MariaDB.
```
mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p
```
1. Entrez le mot de passe de l'utilisateur principal quand vous y êtes invité.
Vous verrez des résultats similaires à ce qui suit.
```
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 9738
Server version: 8.0.28 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
```
# Mise à jour des applications pour se connecter aux instances de base de données MySQL à l'aide de nouveaux SSL/TLS certificats
Le 13 janvier 2023, Amazon RDS a publié de nouveaux certificats d'autorité de certification (CA) pour la connexion à vos instances de base de données RDS à l'aide du protocole Secure Socket Layer ou Transport Layer Security (SSL/TLS). Vous trouverez ci-après des informations sur la mise à jour de vos applications afin d’utiliser les nouveaux certificats.
Cette rubrique peut vous aider à déterminer si des applications clientes sont utilisées SSL/TLS pour se connecter à vos instances de base de données. Si tel est le cas, il vous est alors possible de vérifier si ces applications nécessitent une vérification du certificat pour se connecter.
**Note**
Certaines applications sont configurées pour se connecter aux instances de bases de données MySQL uniquement si la vérification du certificat sur le serveur s'effectue avec succès. Pour ces applications, vous devez mettre à jour les magasins d'approbations des applications clientes afin d'inclure les nouveaux certificats de l'autorité de certification.
Vous pouvez spécifier les modes SSL suivants : `disabled`, `preferred` et `required`. Lorsque vous utilisez le mode SSL `preferred` et que le certificat de l'autorité de certification n'existe pas ou n'est pas à jour, la connexion n'utilise plus SSL et s'établit sans chiffrement.
Nous recommandons d'éviter le mode `preferred`. En mode `preferred`, si la connexion rencontre un certificat non valide, elle cesse d'utiliser le chiffrement et continue sans chiffrement.
Une fois que vous avez mis à jour les certificats de l'autorité de certification dans les magasins d'approbations des applications clientes, vous pouvez soumettre les certificats de vos instances de bases de données à une rotation. Nous vous recommandons vivement de tester ces procédures dans un environnement de développement ou intermédiaire avant de les implémenter dans vos environnements de production.
Pour plus d’informations sur la rotation de certificats, consultez [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md). Pour en savoir plus sur le téléchargement de certificats, consultez [](UsingWithRDS.SSL.md). Pour plus d'informations sur l'utilisation SSL/TLS avec les instances de base de données MySQL, consultez[Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS](MySQL.Concepts.SSLSupport.md).
**Topics**
+ [
## Contrôle de la connexion des applications aux instances de bases de données MySQL avec le protocole SSL
](#ssl-certificate-rotation-mysql.determining-server)
+ [
## Contrôle de la nécessité d'une vérification du certificat du client pour qu'il puisse se connecter
](#ssl-certificate-rotation-mysql.determining-client)
+ [
## Mise à jour du magasin d'approbations de votre application
](#ssl-certificate-rotation-mysql.updating-trust-store)
+ [
## Exemple de code Java pour l'établissement de connexions SSL
](#ssl-certificate-rotation-mysql.java-example)
## Contrôle de la connexion des applications aux instances de bases de données MySQL avec le protocole SSL
Si vous utilisez Amazon RDS for MySQL version 5.7, 8.0 ou 8.4 et que le schéma de performance est activé, exécutez la requête suivante pour vérifier si les connexions utilisent le protocole SSL ou TLS. Pour plus d’informations sur l’activation du schéma de performance, consultez [Performance Schema Quick Start](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-quick-start.html) dans la documentation MySQL.
```
mysql> SELECT id, user, host, connection_type
FROM performance_schema.threads pst
INNER JOIN information_schema.processlist isp
ON pst.processlist_id = isp.id;
```
Dans cet exemple de sortie, vous pouvez voir que votre propre session (`admin`) et une application connectée sous le nom de `webapp1` utilisent toutes deux SSL.
```
+----+-----------------+------------------+-----------------+
| id | user | host | connection_type |
+----+-----------------+------------------+-----------------+
| 8 | admin | 10.0.4.249:42590 | SSL/TLS |
| 4 | event_scheduler | localhost | NULL |
| 10 | webapp1 | 159.28.1.1:42189 | SSL/TLS |
+----+-----------------+------------------+-----------------+
3 rows in set (0.00 sec)
```
## Contrôle de la nécessité d'une vérification du certificat du client pour qu'il puisse se connecter
Vous pouvez vérifier si les clients JDBC et les clients MySQL requièrent une vérification du certificat pour pouvoir se connecter.
### JDBC
L'exemple suivant avec MySQL Connector/J 8.0 montre une façon de vérifier les propriétés de connexion JDBC d'une application afin de déterminer si les connexions réussies nécessitent un certificat valide. Pour plus d’informations sur l’ensemble des options de connexion JDBC pour MySQL, consultez [Configuration Properties](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html) dans la documentation MySQL.
Lorsque vous utilisez MySQL Connector/J 8.0, une connexion SSL doit être vérifiée par rapport au certificat du serveur de base de données si vos propriétés de connexion sont `sslMode` définies sur `VERIFY_CA` ou`VERIFY_IDENTITY`, comme dans l'exemple suivant.
```
Properties properties = new Properties();
properties.setProperty("sslMode", "VERIFY_IDENTITY");
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
```
**Note**
Si vous utilisez le MySQL Java Connector v5.1.38 ou version ultérieure, ou le MySQL Java Connector v8.0.9 ou version ultérieure pour vous connecter à vos bases de données, même si vous n'avez pas explicitement configuré vos applications pour vous connecter à vos bases de données, ces pilotes clients sont utilisés SSL/TLS par défautSSL/TLS. In addition, when using SSL/TLS, ils effectuent une vérification partielle du certificat et ne se connectent pas si le certificat du serveur de base de données est expiré.
### MySQL
Les exemples suivants avec le client MySQL montrent deux façons de vérifier la connexion MySQL d'un script pour déterminer si les connexions nécessitent un certificat valide pour réussir. Pour plus d’informations sur l’ensemble des options de connexion avec le client MySQL, consultez [Client-Side Configuration for Encrypted Connections](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) dans la documentation MySQL.
Lorsque vous utilisez le client MySQL versions 5.7 et ultérieures, une connexion SSL nécessite la vérification du certificat CA sur le serveur si pour l’option `--ssl-mode`, vous spécifiez `VERIFY_CA` ou `VERIFY_IDENTITY`, comme illustré dans l’exemple suivant.
```
mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA
```
## Mise à jour du magasin d'approbations de votre application
Pour plus d’informations sur la mise à jour du magasin d’approbations des applications MySQL, consultez [Installing SSL Certificates](https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-ssl-installation.html) dans la documentation MySQL.
Pour plus d’informations sur le téléchargement du certificat racine, consultez [](UsingWithRDS.SSL.md).
Pour obtenir des exemples de scripts qui importent des certificats, consultez [Exemple de script pour importer les certificats dans votre magasin d’approbations](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Note**
Lors de la mise à jour du magasin d’approbations, vous pouvez conserver les certificats plus anciens en complément de l’ajout des nouveaux certificats.
Si vous utilisez le pilote JDBC mysql dans une application, définissez les propriétés suivantes dans l'application.
```
System.setProperty("javax.net.ssl.trustStore", certs);
System.setProperty("javax.net.ssl.trustStorePassword", "password");
```
Lorsque vous démarrez l'application, définissez les propriétés suivantes.
```
java -Djavax.net.ssl.trustStore=/path_to_trust_store/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_trust_store_password com.companyName.MyApplication
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
## Exemple de code Java pour l'établissement de connexions SSL
L'exemple de code suivant montre comment configurer la connexion SSL qui valide le certificat sur le serveur à l'aide de JDBC.
```
public class MySQLSSLTest {
private static final String DB_USER = "username";
private static final String DB_PASSWORD = "password";
// This trust store has only the prod root ca.
private static final String TRUST_STORE_FILE_PATH = "file-path-to-trust-store";
private static final String TRUST_STORE_PASS = "trust-store-password";
public static void test(String[] args) throws Exception {
Class.forName("com.mysql.jdbc.Driver");
System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_FILE_PATH);
System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASS);
Properties properties = new Properties();
properties.setProperty("sslMode", "VERIFY_IDENTITY");
properties.put("user", DB_USER);
properties.put("password", DB_PASSWORD);
Connection connection = null;
Statement stmt = null;
ResultSet rs = null;
try {
connection = DriverManager.getConnection("jdbc:mysql://mydatabase.123456789012.us-east-1.rds.amazonaws.com:3306",properties);
stmt = connection.createStatement();
rs=stmt.executeQuery("SELECT 1 from dual");
} finally {
if (rs != null) {
try {
rs.close();
} catch (SQLException e) {
}
}
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
}
}
if (connection != null) {
try {
connection.close();
} catch (SQLException e) {
e.printStackTrace();
}
}
}
return;
}
}
```
**Important**
Une fois que vous avez déterminé que vos connexions à la base de données utilisent SSL/TLS et que vous avez mis à jour votre magasin de confiance d'applications, vous pouvez mettre à jour votre base de données pour utiliser les certificats rds-ca-rsa 2048-g1. Pour obtenir des instructions, consultez l’étape 3 dans [Mise à jour de votre certificat CA en modifiant votre instance de base de données ou votre cluster](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating).
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
# Utilisation de l’authentification Kerberos pour Amazon RDS for MySQL
Vous pouvez utiliser l'authentification Kerberos pour authentifier les utilisateurs lorsqu'ils se connectent à votre instance de base de données MySQL. L'instance de base de données fonctionne avec AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) pour activer l'authentification Kerberos. Lorsque les utilisateurs s'authentifient avec une instance de base de données MySQL jointe au domaine d'approbation, les demandes d'authentification sont transférées. Les demandes transférées sont redirigées vers le répertoire de domaines que vous avez crééDirectory Service.
Vous pouvez gagner du temps et de l'argent en conservant toutes les informations d'identification dans le même annuaire. Cette approche vous permet d'avoir un endroit centralisé de stockage et de gestion des informations d'identification pour plusieurs instances de base de données. L’utilisation d’un annuaire peut également améliorer votre profil de sécurité global.
## Disponibilité des régions et des versions
La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour obtenir plus d'informations sur la disponibilité des versions et des régions d'Amazon RDS avec authentification Kerberos, consultez [Régions et moteurs de base de données pris en charge pour l’authentification Kerberos dans Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md).
## Vue d'ensemble de la configuration de l'authentification Kerberos pour les instances de bases de données MySQL
Pour configurer l'authentification Kerberos pour une instance de base de données MySQL, effectuez les étapes générales suivantes, décrites plus en détails par la suite :
1. AWS Managed Microsoft ADÀ utiliser pour créer un AWS Managed Microsoft AD répertoire. Vous pouvez utiliser le AWS Management ConsoleAWS CLI, le ou le Directory Service pour créer le répertoire. Pour plus de détails à ce sujet, consultez la section [Créer votre AWS Managed Microsoft AD répertoire](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) dans le *Guide d'AWS Directory Serviceadministration*.
1. Créez un rôle Gestion des identités et des accès AWS (IAM) qui utilise la politique IAM gérée. `AmazonRDSDirectoryServiceAccess` Le rôle autorise Amazon RDS à effectuer des appels vers votre annuaire.
Pour que le rôle autorise l'accès, le point de terminaison AWS Security Token Service (AWS STS) doit être activé dans le Région AWS AWS compte. AWS STSles points de terminaison sont actifs par défaut dans tous les casRégions AWS, et vous pouvez les utiliser sans autre action. Pour plus d'informations, consultez la section [Activation et désactivation AWS STS dans](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) et Région AWS dans le guide de l'*utilisateur IAM*.
1. Créez et configurez des utilisateurs dans l'AWS Managed Microsoft ADannuaire à l'aide des outils Microsoft Active Directory. Pour plus d'informations sur la création d'utilisateurs dans votre Active Directory, voir [Gérer les utilisateurs et les groupes dans Microsoft AD AWS géré](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) dans le *Guide d'AWS Directory Serviceadministration*.
1. Créez ou modifiez une instance de base de données MySQL. Si vous utilisez CLI ou l’API RDS dans la demande de création, spécifiez un identifiant de domaine avec le paramètre `Domain`. Utilisez l’identifiant `d-*` généré lors de la création de votre annuaire et le nom du rôle que vous avez créé.
Si vous modifiez une instance de base de données MySQL existante pour utiliser l'authentification Kerberos, définissez les paramètres de domaine et de rôle IAM pour l'instance de base de données. Recherchez l'instance de base de données dans le même VPC que l'annuaire de domaine.
1. Utilisez les informations d'identification de l'utilisateur principal Amazon RDS pour vous connecter à l'instance de base de données MySQL. Créez l'utilisateur dans MySQL en utilisant la clause `CREATE USER` `IDENTIFIED WITH 'auth_pam'`. Les utilisateurs que vous créez de cette façon peuvent se connecter à l'instance de base de données MySQL en utilisant l'authentification Kerberos.
## Configuration de l'authentification Kerberos pour les instances de base de données MySQL
Vous l'utilisez AWS Managed Microsoft AD pour configurer l'authentification Kerberos pour une instance de base de données MySQL. Pour configurer l'authentification Kerberos, procédez comme suit :
### Étape 1 : créer un répertoire à l'aide de AWS Managed Microsoft AD
Directory Servicecrée un Active Directory entièrement géré dans le AWS cloud. Lorsque vous créez un AWS Managed Microsoft AD annuaire, il Directory Service crée deux contrôleurs de domaine et des serveurs DNS (Domain Name System) en votre nom. Les serveurs de répertoire sont créés dans des sous-réseaux différents d’un VPC. Cette redondance permet de s’assurer que votre annuaire reste accessible, y compris en cas de défaillance.
Lorsque vous créez un AWS Managed Microsoft AD répertoire, il Directory Service exécute les tâches suivantes en votre nom :
+ Configuration d'un annuaire Active Directory dans le VPC.
+ Création d'un compte d'administrateur d'annuaire avec le nom d'utilisateur Admin et le mot de passe spécifié. Ce compte est utilisé pour gérer votre annuaire.
**Note**
N'oubliez pas d'enregistrer ce mot de passe. Directory Servicene le stocke pas. Vous pouvez le réinitialiser, mais vous ne pouvez pas le récupérer.
+ Création d’un groupe de sécurité pour les contrôleurs de l’annuaire.
Lorsque vous lancez unAWS Managed Microsoft AD, AWS crée une unité organisationnelle (UO) qui contient tous les objets de votre répertoire. Cette unité organisationnelle, qui porte le nom NetBIOS que vous avez saisi lorsque vous avez créé votre annuaire, est située dans la racine du domaine. La racine du domaine est détenue et gérée parAWS.
Le compte administrateur créé avec votre AWS Managed Microsoft AD annuaire dispose d'autorisations pour les activités administratives les plus courantes de votre unité d'organisation :
+ Création, mise à jour et suppression des utilisateurs
+ Ajouter des ressources à votre domaine, comme des serveurs de fichiers ou d’impression, puis attribuer des autorisations pour ces ressources aux utilisateurs dans votre unité organisationnelle
+ Créez des conteneurs OUs et des conteneurs supplémentaires
+ Déléguer des autorités
+ Restaurer des objets supprimés de la corbeille Active Directory
+ Exécuter les PowerShell modules Windows AD et DNS sur le service Web Active Directory
Le compte Admin dispose également de droits pour exécuter les activités suivantes au niveau du domaine :
+ Gérer les configurations DNS (ajouter, supprimer ou mettre à jour des enregistrements, des zones et des redirecteurs)
+ Afficher les journaux d’événements DNS
+ Afficher les journaux d’événements de sécurité
**Pour créer un répertoire avec AWS Managed Microsoft AD**
1. Connectez-vous à la Directory Service console AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).
1. Dans le panneau de navigation, choisissez **Directories** (Répertoires), puis **Set up Directory** (Configurer un répertoire).
1. Choisissez **AWS Managed Microsoft AD**. AWS Managed Microsoft ADest la seule option que vous pouvez actuellement utiliser avec Amazon RDS.
1. Entrez les informations suivantes :
**Nom de DNS de l’annuaire**
Nom complet de l’annuaire, par exemple **corp.example.com**.
**Nom NetBIOS de l’annuaire**
Nom court de l’annuaire, par exemple **CORP**.
**Description de l’annuaire**
(Facultatif) Une description de l’annuaire.
**Mot de passe administrateur**
Mot de passe de l'administrateur de l'annuaire. Le processus de création d’un annuaire crée un compte d’administrateur avec le nom d’utilisateur Admin et ce mot de passe.
Le mot de passe de l'administrateur de l'annuaire ne peut pas contenir le terme « admin ». Le mot de passe est sensible à la casse et doit comporter entre 8 et 64 caractères. Il doit également contenir au moins un caractère de trois des quatre catégories suivantes :
+ Lettres minuscules (a–z)
+ Lettres majuscules (A–Z)
+ Chiffres (0–9)
+ Caractères non alphanumériques (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"’<>,.?/)
**Confirmer le mot de passe**
Saisissez à nouveau le mot de passe de l'administrateur.
1. Choisissez **Suivant**.
1. Entrez les informations suivantes dans la section **Networking** (Réseaux), puis choisissez **Suivant** (Next) :
**VPC**
VPC de l'annuaire. Créez l'instance de base de données MySQL dans ce même VPC.
**Sous-réseaux**
Sous-réseaux pour les serveurs d’annuaires. Les deux sous-réseaux doivent être dans des zones de disponibilité différentes.
1. Vérifiez les informations concernant l’annuaire et effectuez les modifications nécessaires. Lorsque les informations sont correctes, choisissez **Create directory (Créer l’annuaire)**.
![\[La fenêtre Réviser et créer lors de la création du répertoire dans la Directory Service console.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
La création de l’annuaire prend plusieurs minutes. Lorsqu’il est créé, la valeur du champ **Statut** devient **Actif**.
Pour consulter les informations relatives à votre annuaire, choisissez le nom de l'annuaire dans la liste. Notez la valeur **ID de l'annuaire**, car vous avez besoin de cette valeur lorsque vous créez ou modifiez votre instance de base de données MySQL.
![\[La section Détails du répertoire avec l'ID du répertoire dans la Directory Service console.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
### Étape 2 : Créer le rôle IAM qui sera utilisé par Amazon RDS
Pour qu'Amazon RDS puisse vous appelerDirectory Service, un rôle IAM utilisant la politique `AmazonRDSDirectoryServiceAccess` IAM gérée est requis. Ce rôle permet à Amazon RDS d’appeler l’Directory Service.
Lorsqu'une instance de base de données est créée à l'aide de AWS Management Console et que l'utilisateur de la console dispose de l'`iam:CreateRole`autorisation, la console crée automatiquement ce rôle. Dans ce cas, le nom du rôle est `rds-directoryservice-kerberos-access-role`. Sinon, vous devez créer le rôle IAM manuellement. Lorsque vous créez ce rôle IAM`Directory Service`, choisissez et associez la politique AWS gérée `AmazonRDSDirectoryServiceAccess` à celui-ci.
Pour plus d'informations sur la création de rôles IAM pour un service, consultez la section [Création d'un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le Guide de l'*utilisateur IAM*.
**Note**
Le rôle IAM utilisé pour l'authentification Windows pour RDS for SQL Server ne peut pas être utilisé pour RDS for MySQL.
Vous pouvez également créer des politiques avec les autorisations obligatoires au lieu d’utiliser la politique gérée IAM `AmazonRDSDirectoryServiceAccess`. Dans ce cas, le rôle IAM doit avoir la politique d’approbation IAM suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Le rôle doit également avoir la politique de rôle IAM suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
### Étape 3 : Créer et configurer des utilisateurs
Vous pouvez créer des utilisateurs à l’aide de l’outil Active Directory Users and Computers. Cet outil fait partie des outils Active Directory Domain Services et Active Directory Lightweight Directory Services (Services de domaine Active Directory et Services d’annuaire légers Active Directory). Les utilisateurs représentent des individus ou des entités individuelles qui ont accès à votre annuaire.
Pour créer des utilisateurs dans un Directory Service annuaire, vous devez être connecté à une EC2 instance Amazon basée sur Microsoft Windows. Cette instance doit être membre de l'Directory Serviceannuaire et être connectée en tant qu'utilisateur autorisé à créer des utilisateurs. Pour plus d’informations, consultez [Gérer des utilisateurs et des groupes dans AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html) dans le *Guide d’administration d’AWS Directory Service*.
### Étape 4 : Créer ou modifier une instance de base de données MySQL
Créez ou modifiez une instance de base de données MySQL à utiliser avec votre annuaire. Vous pouvez utiliser la console, CLI ou l'API RDS pour associer une instance de base de données à un annuaire. Vous pouvez effectuer cette opération de différentes manières :
+ Créez une nouvelle instance de base de données MySQL à l'aide de la console, de la commande [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI ou de l'opération [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API.
Pour obtenir des instructions, veuillez consulter [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données MySQL existante à l'aide de la console, de la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI ou de l'opération [DBInstanceModify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API.
Pour obtenir des instructions, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
+ Restaurez une instance de base de données MySQL à partir d'un instantané de base de données à l'aide de la console, de la commande CLI [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) ou de [l'opération DBInstance Restore DBSnapshot From](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API.
Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
+ Restaurez une instance de base de données MySQL à point-in-time l'aide de la console, de la commande [ restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI ou de l'opération [Restore DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API.
Pour obtenir des instructions, veuillez consulter [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
L'authentification Kerberos est uniquement prise en charge pour les instances de base de données MySQL dans un VPC. L'instance de base de données peut être dans le même VPC que l'annuaire ou dans un VPC différent. L'instance de base de données doit utiliser un groupe de sécurité qui accepte les sorties du VPC, afin que l'instance de base de données puisse communiquer avec l'annuaire.
Lorsque vous utilisez la console pour créer, modifier ou restaurer une instance de bases de données, choisissez **Mot de passe et authentification Kerberos** dans la section **Authentification de base de données**. Choisissez **Browse Directory** (Parcourir les répertoires), puis sélectionnez le répertoire, ou choisissez **Create a new directory** (Créer un nouveau répertoire).
![\[La section Authentification de base de données avec mot de passe et authentification Kerberos sélectionnée dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/kerberos-authentication.png)
Lorsque vous utilisez l'API AWS CLI ou RDS, associez une instance de base de données à un répertoire. Les paramètres suivants sont nécessaires pour que l'instance de base de données utilise l'annuaire du domaine que vous avez créé :
+ Pour le paramètre `--domain`, vous devez indiquer l’identifiant du domaine (identifiant « d-\$1 ») généré lors de la création de l’annuaire.
+ Pour le paramètre `--domain-iam-role-name`, utilisez le rôle que vous avez créé qui utilise la politique IAM gérée `AmazonRDSDirectoryServiceAccess`.
Par exemple, la commande de CLI suivante modifie une instance de base de données de façon à utiliser un annuaire.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--domain d-ID \
--domain-iam-role-name role-name
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--domain d-ID ^
--domain-iam-role-name role-name
```
**Important**
Si vous modifiez une instance de base de données de façon à activer l’authentification Kerberos, redémarrez l’instance de base de données après avoir effectué la modification.
### Étape 5 : Créer les connexions MySQL d'authentification Kerberos
Utilisez les informations d'identification de l'utilisateur principal Amazon RDS pour vous connecter à l'instance de base de données MySQL comme vous le faites pour n'importe quelle instance de base de données. L'instance de base de données est jointe au AWS Managed Microsoft AD domaine. Vous pouvez ainsi allouer les connexions et utilisateurs MySQL depuis les utilisateurs Active Directory de votre domaine. Les autorisations de base de données sont gérées via des autorisations MySQL standard qui sont accordées et révoquées à partir de ces connexions.
Vous pouvez autoriser un utilisateur Active Directory à s'authentifier avec MySQL. Pour ce faire, utilisez d'abord les informations d'identification de l'utilisateur principal Amazon RDS pour vous connecter à l'instance de base de données MySQL comme avec n'importe quelle autre instance de base de données. Une fois connecté, créez un utilisateur authentifié en externe avec PAM (Pluggable Authentication Modules) dans MySQL, en exécutant la commande suivante. Remplacez `testuser` par le nom de l'utilisateur.
```
CREATE USER 'testuser'@'%' IDENTIFIED WITH 'auth_pam';
```
Les utilisateurs (personnes et applications) de votre domaine peuvent désormais se connecter à l'instance de base de données à partir d'un ordinateur client joint au domaine à l'aide de l'authentification Kerberos.
**Important**
Nous recommandons vivement aux clients d'utiliser des SSL/TLS connexions lorsqu'ils utilisent l'authentification PAM. S'ils n'utilisent pas de SSL/TLS connexion, le mot de passe peut être envoyé en texte clair dans certains cas. Pour exiger une connexion SSL/TLS cryptée pour votre utilisateur AD, exécutez la commande suivante et remplacez-la `testuser` par le nom d'utilisateur :
```
ALTER USER 'testuser'@'%' REQUIRE SSL;
```
Pour de plus amples informations, veuillez consulter [Prise en charge de SSL/TLS pour les instances de base de données MySQL sur Amazon RDS](MySQL.Concepts.SSLSupport.md).
## Gestion d'une instance de base de données dans un domaine
Vous pouvez utiliser CLI ou l'API RDS pour gérer votre instance de base de données et sa relation avec votre annuaire géré Active Directory. Par exemple, vous pouvez associer un annuaire Active Directory pour l'authentification Kerberos et dissocier un annuaire Active Directory pour désactiver l'authentification Kerberos. Vous pouvez également transférer une instance de base de données vers une autre afin qu'elle soit authentifiée en externe par un annuaire Active Directory.
Par exemple, l'API Amazon RDS vous permet d'effectuer les actions suivantes :
+ Pour retenter l'activation de l'authentification Kerberos en cas d'échec d'appartenance, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'ID d'annuaire d'appartenance actuelle.
+ Pour mettre à jour le nom du rôle IAM de l'appartenance, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'ID d'annuaire de l'appartenance actuelle et le nouveau rôle IAM.
+ Pour désactiver l'authentification Kerberos sur une instance de base de données, utilisez l'opération d'API `ModifyDBInstance` et spécifiez `none` comme paramètre de domaine.
+ Pour déplacer une instance de base de données d'un domaine à un autre, utilisez l'opération d'API `ModifyDBInstance` et spécifiez l'identifiant du nouveau domaine en tant que paramètre de domaine.
+ Pour répertorier l'appartenance pour chaque instance de base de données, utilisez l'opération d'API `DescribeDBInstances`.
### Présentation de l'appartenance au domaine
Après la création ou la modification de votre instance de base de données, elle devient un membre du domaine. Vous pouvez consulter l'état de l'appartenance au domaine de l'instance de base de données en exécutant la commande [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI. Le statut de l'instance de base de données peut avoir les valeurs suivantes :
+ `kerberos-enabled` : l’instance de base de données a l’authentification Kerberos activée.
+ `enabling-kerberos`— AWS est en train d'activer l'authentification Kerberos sur cette instance de base de données.
+ `pending-enable-kerberos` – L'activation de l'authentification Kerberos est en attente sur cette instance de base de données.
+ `pending-maintenance-enable-kerberos`— AWS tentera d'activer l'authentification Kerberos sur l'instance de base de données lors de la prochaine fenêtre de maintenance planifiée.
+ `pending-disable-kerberos` – La désactivation de l'authentification Kerberos est en attente sur cette instance de base de données.
+ `pending-maintenance-disable-kerberos`— AWS tentera de désactiver l'authentification Kerberos sur l'instance de base de données lors de la prochaine fenêtre de maintenance planifiée.
+ `enable-kerberos-failed` – Un problème de configuration a empêché AWS d'activer l'authentification Kerberos sur l'instance de base de données. Vérifiez et corrigez votre configuration avant d'émettre à nouveau la commande de modification de l'instance de base de données.
+ `disabling-kerberos`— AWS est en train de désactiver l'authentification Kerberos sur cette instance de base de données.
Une demande d'activation de l'authentification Kerberos peut échouer à cause d'un problème de connectivité réseau ou d'un rôle IAM incorrect. Par exemple, supposons que vous créez une instance de base de données ou modifiez une instance de base de données et que la tentative d'activation de l'authentification Kerberos échoue. Si cela se produit, réémettez la commande modify ou modifiez l'instance de base de données nouvellement créée pour joindre le domaine.
## Connexion à MySQL avec l'authentification Kerberos
Pour vous connecter à MySQL avec l'authentification Kerberos, vous devez vous connecter à l'aide du type d'authentification Kerberos.
Pour créer un utilisateur de base de données auquel vous pouvez vous connecter à l'aide de l'authentification Kerberos, utilisez une clause `IDENTIFIED WITH` avec l'instruction `CREATE USER`. Pour obtenir des instructions, consultez [Étape 5 : Créer les connexions MySQL d'authentification Kerberos](#mysql-kerberos-setting-up.create-logins).
Pour éviter les erreurs, utilisez le client `mysql` MariaDB. Vous pouvez télécharger le logiciel MariaDB à l'adresse [https://downloads.mariadb.org/](https://downloads.mariadb.org/).
À partir d'une invite de commande, connectez-vous à un des points de terminaison associés à votre instance de base de données MySQL. Suivez les procédures générales décrites dans [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md). Lorsque vous êtes invité à entrer le mot de passe, entrez le mot de passe Kerberos associé à ce nom d'utilisateur.
## Restauration d'une instance de base de données MySQL et ajout de cette instance à un domaine
Vous pouvez restaurer un instantané de base de données ou terminer la point-in-time restauration d'une instance de base de données MySQL, puis l'ajouter à un domaine. Une fois que l'instance de base de données est restaurée, modifiez l'instance de base de données à l'aide du processus expliqué dans [Étape 4 : Créer ou modifier une instance de base de données MySQL](#mysql-kerberos-setting-up.create-modify) afin d'ajouter l'instance de base de données à un domaine.
## Limitations MySQL de l'authentification Kerberos
Les limitations suivantes s'appliquent à l'authentification Kerberos pour MySQL :
+ Seul un AWS Managed Microsoft AD est pris en charge. Toutefois, vous pouvez joindre des instances de base de données RDS for MySQL à des domaines Microsoft AD gérés partagés qui appartiennent à différents comptes dans la même Région AWS.
+ Vous devez redémarrer l'instance de base de données après avoir activé la fonctionnalité.
+ La longueur du nom de domaine ne peut pas dépasser 61 caractères.
+ Vous ne pouvez pas activer l'authentification Kerberos et l'authentification IAM en même temps. Choisissez l'une ou l'autre des méthodes d'authentification pour votre instance de base de données MySQL.
+ Ne modifiez pas le port d'instance de base de données après avoir activé la fonctionnalité.
+ N'utilisez pas l'authentification Kerberos avec les réplicas en lecture.
+ Si la mise à niveau automatique des versions mineures est activée pour une instance de base de données MySQL qui utilise l'authentification Kerberos, vous devez désactiver cette authentification, puis la réactiver après une mise à niveau automatique. Pour plus d'informations sur les mises à niveau automatiques des versions mineures, consultez [Mises à niveau automatiques des versions mineures pour RDS for MySQL](USER_UpgradeDBInstance.MySQL.Minor.md).
+ Pour supprimer une instance de base de données pour laquelle cette fonctionnalité est activée, désactivez d'abord la fonctionnalité. Pour ce faire, utilisez la commande d’interface de ligne de commande `modify-db-instance` pour l’instance de base de données et spécifiez `none` pour le paramètre `--domain`.
Si vous utilisez CLI ou l'API RDS pour supprimer une instance de base de données pour laquelle cette fonctionnalité est activée, laissez s'écouler un délai.
+ RDS for MySQL ne prend pas en charge l’authentification Kerberos via une approbation de forêt entre votre AD sur site ou auto-hébergé et le AWS Managed Microsoft AD.
# Amélioration des performances des requêtes pour RDS for MySQL avec Lectures optimisées pour Amazon RDS
Vous pouvez accélérer le traitement des requêtes pour RDS for MySQL avec Amazon RDS Optimized Reads. Une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL qui utilise l'option RDS Optimized Reads peut traiter les requêtes jusqu'à 2 fois plus rapidement qu'une instance de base de données ou un cluster de bases de données qui ne l'utilise pas.
**Topics**
+ [
## Présentation de RDS Optimized Reads
](#rds-optimized-reads-overview)
+ [
## Cas d'utilisation pour RDS Optimized Reads
](#rds-optimized-reads-use-cases)
+ [
## Bonnes pratiques relatives à RDS Optimized Reads
](#rds-optimized-reads-best-practices)
+ [
## Utilisation de RDS Optimized Reads
](#rds-optimized-reads-using)
+ [
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
](#rds-optimized-reads-monitoring)
+ [
## Limites pour RDS Optimized Reads
](#rds-optimized-reads-limitations)
## Présentation de RDS Optimized Reads
Lorsque vous utilisez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL avec l'option RDS Optimized Reads activée, les performances de requête sont plus rapides grâce à l'utilisation d'un stockage d'instances. Un *stockage d'instances* fournit un stockage temporaire de niveau bloc pour votre instance de base de données ou votre cluster de bases de données multi-AZ. Le stockage repose sur des disques SSD (Solid State Drive) NVMe (Non-Volatile Memory Express) qui sont physiquement attachés au serveur hôte. Ce stockage est optimisé pour une faible latence, de hautes performances d'E/S aléatoires et un haut débit de lecture séquentielle.
RDS Optimized Reads est activé par défaut lorsqu'une instance de base de données ou un cluster de bases de données multi-AZ utilise une classe d'instances de base de données avec un stockage d'instances, tel que db.m5d ou db.m6gd. Avec RDS Optimized Reads, certains objets temporaires sont stockés dans le stockage d'instances. Ces objets temporaires incluent des fichiers temporaires internes, des tables temporaires internes sur disque, des fichiers de mappage de mémoire et des fichiers de cache de journal binaire (binlog). Pour plus d’informations sur le stockage d’instances, consultez [Stockage d’instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud pour les instances Linux*.
Les charges de travail qui génèrent des objets temporaires dans MySQL pour le traitement des requêtes peuvent tirer parti du stockage d'instances pour accélérer le traitement des requêtes. Ce type de charge de travail inclut les requêtes impliquant des tris, des agrégations de hachage, des jointures à charge élevée, des expressions de table communes (CTE) et des requêtes sur des colonnes non indexées. Ces volumes de stockage d'instances fournissent des IOPS et des performances supérieures, quelles que soient les configurations de stockage utilisées pour le stockage Amazon EBS persistant. Étant donné que RDS Optimized Reads décharge les opérations sur les objets temporaires dans le stockage d'instances, les opérations d'entrée/sortie par seconde (IOPS) ou le débit du stockage persistant (Amazon EBS) peuvent désormais être utilisés pour les opérations sur les objets persistants. Ces opérations incluent des lectures et des écritures régulières de fichiers de données, ainsi que des opérations de moteur en arrière-plan, telles que le vidage et la fusion de mémoires tampon par insertion.
**Note**
Les instantanés RDS manuels et automatisés ne contiennent que des fichiers de moteur pour les objets persistants. Les objets temporaires créés dans le stockage d'instances ne sont pas inclus dans les instantanés RDS.
## Cas d'utilisation pour RDS Optimized Reads
Si vous avez des charges de travail qui dépendent fortement d'objets temporaires, tels que des tables ou des fichiers internes, pour l'exécution de leurs requêtes, vous pouvez tirer parti de l'activation de RDS Optimized Reads. Les cas d'utilisation suivants sont propices à RDS Optimized Reads :
+ Applications exécutant des requêtes analytiques avec des expressions de table communes (CTE), des tables dérivées et des opérations de regroupement complexes
+ Réplicas en lecture qui traitent un trafic de lecture important avec des requêtes non optimisées
+ Applications exécutant des requêtes de création de rapport à la demande ou dynamiques impliquant des opérations complexes, telles que des requêtes avec des clauses `GROUP BY` et `ORDER BY`
+ Charges de travail utilisant des tables temporaires internes pour le traitement des requêtes
Vous pouvez surveiller la variable de statut du moteur `created_tmp_disk_tables` pour déterminer le nombre de tables temporaires sur disque créées sur votre instance de base de données.
+ Applications qui créent de grandes tables temporaires, directement ou dans le cadre de procédures, pour stocker des résultats intermédiaires
+ Requêtes de base de données qui regroupent ou trient des colonnes non indexées
## Bonnes pratiques relatives à RDS Optimized Reads
Utilisez les bonnes pratiques suivantes pour RDS Optimized Reads :
+ Ajoutez une logique de nouvelle tentative pour les requêtes en lecture seule au cas où elles échoueraient en raison d'un stockage d'instances complet pendant l'exécution.
+ Surveillez l'espace de stockage disponible sur le stockage d'instances à l'aide de la métrique CloudWatch `FreeLocalStorage`. Si le stockage d'instances atteint sa limite en raison de la charge de travail sur l'instance de base de données, modifiez l'instance de base de données pour utiliser une classe d'instances de base de données plus grande.
+ Lorsque votre instance de base de données ou votre cluster de bases de données multi-AZ dispose de suffisamment de mémoire mais atteint toujours la limite de stockage sur le stockage d'instances, augmentez la valeur `binlog_cache_size` pour conserver en mémoire les entrées binlog spécifiques à la session. Cette configuration empêche l'écriture des entrées binlog dans les fichiers de cache binlog temporaires sur le disque.
Le paramètre `binlog_cache_size` est spécifique à la session. Vous pouvez modifier cette valeur pour chaque nouvelle session. Le réglage de ce paramètre peut augmenter l'utilisation de la mémoire sur l'instance de base de données pendant les pics de charge de travail. Par conséquent, envisagez d'augmenter la valeur du paramètre en fonction du modèle de charge de travail de votre application et de la mémoire disponible sur l'instance de base de données.
+ Pour MySQL versions 8.0 et antérieures, utilisez la valeur par défaut de `MIXED` pour le paramètre `binlog_format`. En fonction de la taille des transactions, le réglage de `binlog_format` sur `ROW` peut entraîner la création de fichiers de cache binlog volumineux sur le stockage d'instances. Pour MySQL 8.4 et versions ultérieures, utilisez la valeur par défaut de `ROW` pour le paramètre `binlog_format`.
+ Définissez le paramètre [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) sur `TempTable` et définissez le paramètre [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) pour qu'il corresponde à la taille du stockage disponible sur le stockage d'instances.
+ Évitez d'effectuer des modifications en bloc dans une transaction unique. Ces types de transactions peuvent générer de gros fichiers de cache binlog sur le stockage d'instances et peuvent provoquer des problèmes lorsque le stockage d'instances est plein. Envisagez de diviser les écritures en plusieurs petites transactions afin de réduire au maximum l'utilisation de l'espace de stockage pour les fichiers de cache binlog.
+ Utilisez la valeur par défaut de `ABORT_SERVER` pour le paramètre `binlog_error_action`. Cela évite les problèmes liés à la journalisation binaire sur les instances de base de données lorsque les sauvegardes sont activées.
## Utilisation de RDS Optimized Reads
Lorsque vous provisionnez une instance de base de données RDS for MySQL avec l'une des classes d'instances de base de données suivantes dans le cadre d'un déploiement d'instance de base de données mono-AZ ou multi-AZ, ou d'un déploiement de cluster de bases de données multi-AZ, l'instance de base de données utilise automatiquement les lectures optimisées pour RDS.
Pour activer RDS Optimized Reads, effectuez l'une des actions suivantes :
+ Créez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL en utilisant l'une de ces classes d'instances de base de données. Pour plus d’informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Modifiez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL existant afin d'utiliser l'une de ces classes d'instances de base de données. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
La fonctionnalité Lectures optimisées pour RDS est disponible dans toutes les Régions AWS RDS où une ou plusieurs des classes d'instances de base de données avec stockage SSD NVMe local sont prises en charge. Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
La disponibilité des classes d'instance de base de données varie pour les Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une Région AWS spécifique, consultez [Déterminer le support des classes d'instance de base de données dans Régions AWS](Concepts.DBInstanceClass.RegionSupport.md).
Si vous ne souhaitez pas utiliser RDS Optimized Reads, modifiez votre instance de base de données ou votre cluster de bases de données multi-AZ, afin de ne pas utiliser une classe d'instances de base de données prenant en charge cette fonctionnalité.
## Surveillance des instances de base de données qui utilisent RDS Optimized Reads
Vous pouvez surveiller les instances de base de données qui utilisent RDS Optimized Reads à l'aide des métriques CloudWatch suivantes :
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
Ces métriques fournissent des données sur le stockage disponible dans le stockage d'instances, les IOPS et le débit. Pour plus d’informations sur ces métriques, consultez [Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS](rds-metrics.md#rds-cw-metrics-instance).
## Limites pour RDS Optimized Reads
Les limites suivantes s'appliquent à RDS Optimized Reads :
+ RDS Optimized Reads est pris en charge pour les versions suivantes :
+ RDS for MySQL version 8.0.28 et versions ultérieures majeures et mineures
Pour obtenir des informations sur les versions de RDS for MySQL, consultez [Versions de MySQL sur Amazon RDS](MySQL.Concepts.VersionMgmt.md).
+ Vous ne pouvez pas remplacer l'emplacement des objets temporaires par un stockage persistant (Amazon EBS) dans les classes d'instances de base de données qui prennent en charge RDS Optimized Reads.
+ Lorsque la journalisation binaire est activée sur une instance de base de données, la taille maximale des transactions est limitée par la taille du stockage d'instances. Pour MySQL, toute session qui nécessite plus de stockage que la valeur de `binlog_cache_size` écrit les modifications des transactions dans les fichiers de cache de journaux binaires temporaires, qui sont créés dans le stockage d'instances.
+ Les transactions peuvent échouer lorsque le stockage d'instances est plein.
# Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL
Vous pouvez améliorer les performances des transactions d'écriture avec l'option Écritures optimisées pour RDS for MySQL. Lorsque votre base de données RDS for MySQL utilise RDS Optimized Writes, elle peut atteindre un débit de transactions d'écriture jusqu'à deux fois supérieur.
**Topics**
+ [
## Présentation de RDS Optimized Writes
](#rds-optimized-writes-overview)
+ [
## Utilisation de l'option Écritures optimisées pour RDS
](#rds-optimized-writes-using)
+ [
## Activation de l'option Écritures optimisées pour RDS sur une base de données existante
](#rds-optimized-writes-modify-enable)
+ [
## Limites pour l'option Écritures optimisées pour RDS
](#rds-optimized-writes-limitations)
## Présentation de RDS Optimized Writes
Lorsque vous activez l'option Écritures optimisées pour RDS, vos bases de données RDS for MySQL n'écrivent qu'une seule fois lors du vidage des données dans un stockage durable sans avoir besoin du tampon à double écriture. Les bases de données continuent de protéger les propriétés ACID pour les transactions de base de données fiables, ainsi que des performances améliorées.
Les bases de données relationnelles, comme MySQL, fournissent les *propriétés ACID* d’atomicité, de cohérence, d’isolement et de durabilité pour des transactions de base de données fiables. Pour fournir ces propriétés, MySQL utilise une zone de stockage de données appelée *tampon à double écriture* qui empêche les erreurs d'écriture de page partielles. Ces erreurs se produisent en cas de panne matérielle alors que la base de données met à jour une page, par exemple en cas de panne de courant. Une base de données MySQL peut détecter les écritures de page partielles et récupérer une copie de la page dans le tampon à double écriture. Cette technique offre une protection, mais elle entraîne également des opérations d'écriture supplémentaires. Pour plus d'informations sur le tampon à double écriture MySQL, consultez [Doublewrite Buffer](https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html) (Tampon à double écriture) dans la documentation MySQL.
Quand RDS Optimized Writes est activé, les bases de données RDS for MySQL n'écrivent qu'une seule fois lors du vidage des données dans un stockage durable sans utiliser le tampon à double écriture. RDS Optimized Writes est utile si vous exécutez des charges de travail lourdes en écriture sur vos bases de données RDS for MySQL. Parmi les bases de données soumises à de lourdes charges de travail en écriture, citons celles qui prennent en charge les paiements numériques, les transactions financières et les applications de jeu.
Ces bases de données s'exécutent sur des classes d'instances de base de données qui utilisent le système AWS Nitro. En raison de la configuration matérielle dans ces systèmes, la base de données peut écrire des pages de 16 Kio directement dans des fichiers de données de manière fiable et durable, en une seule étape. Le système AWS Nitro permet des écritures optimisées RDS.
Vous pouvez définir le nouveau paramètre de base de données `rds.optimized_writes` pour contrôler la fonctionnalité RDS Optimized Writes pour les bases de données RDS for MySQL. Accédez à ce paramètre dans les groupes de paramètres de base de données de RDS for MySQL version 8.0 et RDS for MySQL version 8.4. Définissez ce paramètre sur l'une des valeurs suivantes :
+ `AUTO` : activer RDS Optimized Writes si la base de données le prend en charge. Désactiver RDS Optimized Writes si la base de données ne le prend pas en charge. Il s’agit de la valeur par défaut.
+ `OFF` : désactiver l'option Écritures optimisées pour RDS même si la base de données le prend en charge.
Si vous avez une base de données existante avec une version de moteur, une classe d'instance de base de données, un and/or file system format that doesn't support RDS Optimized Writes, you can enable the feature by creating a blue/green déploiement. Pour de plus amples informations, veuillez consulter [Activation de l'option Écritures optimisées pour RDS sur une base de données existante](#rds-optimized-writes-modify-enable).
Si vous migrez une base de données RDS for MySQL configurée pour utiliser RDS Optimized Writes dans une classe d'instances de base de données qui ne prend pas en charge cette fonctionnalité, RDS désactive automatiquement RDS Optimized Writes pour la base de données.
Lorsque RDS Optimized Writes est désactivé, la base de données utilise le tampon à double écriture MySQL.
Pour déterminer si une base de données RDS for MySQL utilise RDS Optimized Writes, consultez la valeur actuelle du paramètre `innodb_doublewrite` de la base de données. Si la base de données utilise des écritures optimisées RDS, ce paramètre est défini sur `FALSE` (`0`).
## Utilisation de l'option Écritures optimisées pour RDS
Vous pouvez activer les écritures optimisées RDS lorsque vous créez une base de données RDS pour MySQL à l'aide de la console RDS, de l'API RDS ou de l' AWS CLI API RDS. L'option Écritures optimisées pour RDS est automatiquement activé lorsque les deux conditions suivantes s'appliquent dans le cadre de la création de la base de données :
+ Vous spécifiez une version du moteur de base de données et une classe d'instances de base de données qui prennent en charge l'option Écritures optimisées pour RDS.
+ RDS Optimized Writes est pris en charge pour RDS for MySQL 8.0.30 et versions ultérieures. Pour obtenir des informations sur les versions de RDS for MySQL, consultez [Versions de MySQL sur Amazon RDS](MySQL.Concepts.VersionMgmt.md).
+ RDS Optimized Writes est pris en charge pour les bases de données RDS for MySQL qui utilisent les classes d'instances de base de données suivantes :
+ db.m7i
+ db.m7g
+ db.m6g
+ db.m6gd
+ db.m6i
+ db.m5
+ db.m5d
+ db.r7i
+ db.r7g
+ db.r6g
+ db.r6gd
+ db.r6i
+ db.r5
+ db.r5b
+ db.r5d
+ db.x2idn
+ db.x2iedn
Pour plus d’informations sur les classes d’instance de base de données, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
La disponibilité des classes d'instances de base de données diffère pour Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une classe spécifique Région AWS, consultez[Déterminer le support des classes d'instance de base de données dans Régions AWS](Concepts.DBInstanceClass.RegionSupport.md).
Pour mettre à niveau votre base de données vers une classe d'instance de base de données prenant en charge les écritures optimisées RDS, vous pouvez créer un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Activation de l'option Écritures optimisées pour RDS sur une base de données existante](#rds-optimized-writes-modify-enable).
+ Dans le groupe de paramètres associé à la base de données, le paramètre `rds.optimized_writes` est défini sur `AUTO`. Dans les groupes de paramètres par défaut, ce paramètre est toujours défini sur `AUTO`.
Si vous voulez utiliser une version du moteur de base de données et une classe d'instances de base de données qui prennent en charge Écritures optimisées pour RDS, mais que vous ne voulez pas utiliser cette fonction, spécifiez alors un groupe de paramètres personnalisé quand vous créez la base de données. Dans le groupe de paramètres, définissez le paramètre `rds.optimized_writes` sur `OFF`. Si vous souhaitez que la base de données utilise l'option Écritures optimisées pour RDS ultérieurement, vous pouvez définir ce paramètre sur `AUTO` pour l'activer. Pour obtenir des informations sur la création des groupes de paramètres personnalisés et sur la définition des paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Pour plus d’informations sur la création d’une instance de base de données, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
### Console
Lorsque vous utilisez la console RDS pour créer une base de données RDS for MySQL, vous pouvez filtrer les versions du moteur de base de données et les classes d'instances de base de données qui prennent en charge RDS Optimized Writes. Après avoir activé les filtres, vous pouvez choisir parmi les versions du moteur de base de données et les classes d'instances de base de données disponibles.
Pour choisir une version du moteur de base de données prenant en charge RDS Optimized Writes, filtrez les versions du moteur de base de données RDS for MySQL qui le prennent en charge dans **Engine version** (Version du moteur), puis choisissez une version.
![\[La section des Options de moteur avec le filtre Écritures optimisées pour Amazon RDS activé pour la Version du moteur.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter.png)
Dans la section **Instance configuration** (Configuration de l'instance), filtrez les classes d'instances de base de données qui prennent en charge l'option Écritures optimisées pour RDS, puis choisissez une classe d'instances de base de données.
![\[La section Configuration de l’instance avec le filtre Écritures optimisées pour Amazon RDS activé pour la classe d’instance de base de données.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png)
Après avoir effectué ces sélections, vous pouvez choisir d'autres paramètres qui répondent à vos besoins et terminer la création de la base de données RDS for MySQL à l'aide de la console.
### AWS CLI
Pour créer une instance de base de données à l'aide de AWS CLI, exécutez la [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)commande. Veillez à ce que les valeurs `--engine-version` et `--db-instance-class` prennent en charge RDS Optimized Writes. De plus, veillez à ce que le paramètre `rds.optimized_writes` du groupe de paramètres associé à l'instance de base de données soit défini sur `AUTO`. Cet exemple associe le groupe de paramètres par défaut à l'instance de base de données.
**Example Création d'une instance de base de données qui utilise RDS Optimized Writes**
Pour Linux, macOS ou Unix :
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --engine mysql \
4. --engine-version 8.0.30 \
5. --db-instance-class db.r5b.large \
6. --manage-master-user-password \
7. --master-username admin \
8. --allocated-storage 200
```
Pour Windows :
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --engine mysql ^
4. --engine-version 8.0.30 ^
5. --db-instance-class db.r5b.large ^
6. --manage-master-user-password ^
7. --master-username admin ^
8. --allocated-storage 200
```
### API RDS
Vous pouvez créer une instance de base de données à l'aide de l'DBInstanceopération [Create](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Quand vous utilisez cette opération, veillez à ce que les valeurs `EngineVersion` et `DBInstanceClass` prennent en charge RDS Optimized Writes. De plus, veillez à ce que le paramètre `rds.optimized_writes` du groupe de paramètres associé à l'instance de base de données soit défini sur `AUTO`.
## Activation de l'option Écritures optimisées pour RDS sur une base de données existante
Pour modifier une base de données RDS for MySQL existante afin d'activer l'option Écritures optimisées pour RDS, la base de données doit avoir été créée avec une version du moteur de base de données et une classe d'instance de base de données prises en charge. En outre, la base de données doit avoir été créée *après* la publication de l'option Écritures optimisées pour RDS le 27 novembre 2022, car la configuration requise du système de fichiers sous-jacent est incompatible avec celle des bases de données créées avant sa publication. Si ces conditions sont remplies, vous pouvez activer l'option Écritures optimisées pour RDS en définissant le paramètre `rds.optimized_writes` sur `AUTO`.
Si votre base de données *n'a pas* été créée avec une version de moteur, une classe d'instance ou une configuration de système de fichiers prise en charge, vous pouvez utiliser les Blue/Green déploiements RDS pour migrer vers une configuration prise en charge. Lors de la création du blue/green déploiement, procédez comme suit :
+ Sélectionnez **Activer l'option Écritures optimisées pour RDS sur une base de données verte**, puis spécifiez une version du moteur et une classe d'instance de base de données qui prennent en charge l'option Écritures optimisées pour RDS. Pour obtenir la liste des versions de moteur et des classes d'instance prises en charge, consultez [Utilisation de l'option Écritures optimisées pour RDS](#rds-optimized-writes-using).
+ Sous **Stockage**, choisissez **Mettre à niveau la configuration du système de fichiers de stockage**. Cette option met à niveau la base de données vers une configuration de système de fichiers sous-jacent compatible.
Lorsque vous créez le blue/green déploiement, si le `rds.optimized_writes` paramètre est défini sur`AUTO`, les écritures optimisées RDS seront automatiquement activées dans l'environnement vert. Vous pouvez ensuite passer au blue/green déploiement, ce qui fait de l'environnement vert le nouvel environnement de production.
Pour de plus amples informations, veuillez consulter [Création d'un blue/green déploiement dans Amazon RDS ( Aurora)](blue-green-deployments-creating.md).
## Limites pour l'option Écritures optimisées pour RDS
Lorsque vous restaurez une base de données RDS for MySQL à partir d'un instantané, vous pouvez activer l'option Écritures optimisées pour RDS pour cette base de données seulement si toutes les conditions suivantes s'appliquent :
+ L'instantané a été créé à partir d'une base de données qui prend en charge RDS Optimized Writes.
+ L'instantané a été créé à partir d'une base de données qui a été créée *après* le lancement d'Écritures optimisées pour RDS.
+ L'instantané est restauré en une base de données qui prend en charge RDS Optimized Writes.
+ La base de données restaurée est associée à un groupe de paramètres où le paramètre `rds.optimized_writes` est défini sur `AUTO`.
# Mises à niveau du moteur de base de données RDS for MySQL
Lorsque Amazon RDS prend en charge une nouvelle version d'un moteur de base de données, vous pouvez mettre à niveau vos instances de base de données vers cette nouvelle version. Il existe deux types de mises à niveau pour les bases de données MySQL : les mises à niveau des versions majeures et les mises à niveau des versions mineures.
**Mises à niveau de version majeure.**
Les *mises à niveau de version majeure* peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. En conséquence, vous devez effectuer manuellement les mises à niveau des versions majeures de vos instances de base de données. Vous pouvez lancer une mise à niveau de version majeure en modifiant votre instance de base de données. Cependant, avant d’effectuer une mise à niveau de version majeure, nous vous recommandons de suivre les instructions contenues dans [Mises à niveau des versions majeures pour RDS for MySQL](USER_UpgradeDBInstance.MySQL.Major.md).
Pour les mises à niveau des versions majeures des déploiements d’instances de base de données multi-AZ, Amazon RDS met à niveau simultanément les deux réplicas, principal et de secours. L’instance de base de données n’est pas disponible tant que la mise à niveau n’est pas terminée. Pour les mises à niveau des versions majeures des déploiements de clusters de bases de données multi-AZ, Amazon RDS met à niveau les instances membres du cluster une par une.
Vous pouvez minimiser le temps d'arrêt requis pour une mise à niveau de version majeure en utilisant un blue/green déploiement. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
**Mises à niveau de version mineure.**
Les *mises à niveau des versions mineures* contiennent uniquement des modifications rétrocompatibles avec les applications existantes. Vous pouvez lancer manuellement une mise à niveau de version mineure en modifiant votre instance de base de données. Vous pouvez également activer l’option **Mise à niveau automatique des versions mineures** lorsque vous créez ou modifiez une instance de base de données. Dans ce cas, Amazon RDS met automatiquement à niveau l’instance de base de données une fois qu’il a testé et approuvé la nouvelle version. Pour de plus amples informations sur la mise à niveau, veuillez consulter [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
Lorsque vous effectuez une mise à niveau de version mineure d’un cluster de bases de données multi-AZ, Amazon RDS met à niveau les instances de base de données de lecteur une par une. Ensuite, l’une des instances de base de données de lecteur devient la nouvelle instance de base de données d’enregistreur. Amazon RDS met ensuite à niveau l’ancienne instance d’enregistreur (qui est désormais une instance de lecteur).
La durée d’indisponibilité liée à une mise à niveau de version mineure d’un déploiement d’*instance* de base de données multi-AZ peut durer plusieurs minutes. Les clusters de bases de données multi-AZ réduisent généralement la durée d’indisponibilité des mises à niveau des versions mineures à environ 35 secondes. Lorsqu’ils sont utilisés avec le proxy RDS, vous pouvez encore réduire la durée d’indisponibilité à une seconde ou moins. Pour de plus amples informations, veuillez consulter [Proxy Amazon RDS ](rds-proxy.md). Vous pouvez également utiliser un proxy de base de données open source tel que [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/) ou le pilote [AWS Advanced JDBC](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/) Wrapper. [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)
Amazon RDS prend également en charge la politique de déploiement des mises à niveau afin de gérer les mises à niveau automatiques des versions mineures sur plusieurs ressources de base de données et. Comptes AWS Pour de plus amples informations, veuillez consulter [Utilisation de la politique de déploiement des mises à AWS Organizations niveau pour les mises à niveau automatiques des versions mineures](RDS.Maintenance.AMVU.UpgradeRollout.md).
Si votre instance de base de données MySQL utilise des réplicas en lecture, vous devez mettre à niveau tous les réplicas en lecture avant de mettre à niveau l’instance source.
**Topics**
+ [
## Considérations relatives aux mises à niveau de MySQL
](#USER_UpgradeDBInstance.MySQL.Considerations)
+ [
## Recherche de cibles de mise à niveau valides
](#USER_UpgradeDBInstance.MySQL.FindingTargets)
+ [
# Numéros de version de MySQL
](USER_UpgradeDBInstance.MySQL.VersionID.md)
+ [
# Numéros de version RDS dans RDS for MySQL
](USER_UpgradeDBInstance.MySQL.rds.version.md)
+ [
# Mises à niveau des versions majeures pour RDS for MySQL
](USER_UpgradeDBInstance.MySQL.Major.md)
+ [
# Test d’une mise à niveau de RDS for MySQL
](USER_UpgradeDBInstance.MySQL.UpgradeTesting.md)
+ [
## Mise à niveau d'une instance de base de données MySQL
](#USER_UpgradeDBInstance.MySQL.Upgrading)
+ [
# Mises à niveau automatiques des versions mineures pour RDS for MySQL
](USER_UpgradeDBInstance.MySQL.Minor.md)
+ [
# Utilisation d’un réplica en lecture pour réduire la durée d’indisponibilité lors de la mise à niveau d’une base de données RDS for MySQL
](USER_UpgradeDBInstance.MySQL.ReducedDowntime.md)
+ [
# Surveillance des mises à niveau du moteur RDS for MySQL à l'aide d'événements
](USER_UpgradeDBInstance.MySQL.Monitoring.md)
## Considérations relatives aux mises à niveau de MySQL
Amazon RDS prend deux instantanés de base de données ou plus au cours du processus de mise à niveau. Amazon RDS prend jusqu'à deux instantanés de l'instance de base de données *avant* d'apporter des modifications à la mise à niveau. Si la mise à niveau ne fonctionne pas pour vos bases de données, vous pouvez restaurer l'un de ces instantanés pour créer une instance de base de données exécutant l'ancienne version. Amazon RDS prend un autre instantané de l'instance de base de données une fois la mise à niveau terminée. Amazon RDS prend ces instantanés, qu'il AWS Backup gère ou non les sauvegardes de l'instance de base de données.
**Note**
Amazon RDS ne prend des instantanés de base de données que si vous avez défini la période de rétention des sauvegardes de votre instance de base de données sur un nombre supérieur à 0. Pour modifier la période de rétention des sauvegardes, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
Une fois la mise à niveau terminée, vous ne pouvez pas rétablir la version précédente du moteur de base de données. Si vous souhaitez revenir à la version précédente, restaurez le premier instantané de base de données pris pour créer une nouvelle instance de base de données.
Vous contrôlez à quel moment vous mettez à niveau votre instance de base de données vers une nouvelle version prise en charge par Amazon RDS. Ce niveau de contrôle vous aide à maintenir la compatibilité avec des versions de base de données spécifiques et à tester les nouvelles versions avec votre application avant un déploiement en production. Lorsque vous êtes prêt, vous pouvez effectuer des mises à niveau de version aux moments qui conviennent le mieux à votre planning.
Si votre instance de base de données utilise la réplication en lecture, vous devez mettre à niveau tous les réplicas en lecture avant de mettre à niveau l’instance source.
## Recherche de cibles de mise à niveau valides
Lorsque vous utilisez le AWS Management Console pour mettre à niveau une instance de base de données, il affiche les cibles de mise à niveau valides pour l'instance de base de données. Vous pouvez également exécuter la AWS CLI commande suivante pour identifier les cibles de mise à niveau valides pour une instance de base de données :
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mysql \
--engine-version version_number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mysql ^
--engine-version version_number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Par exemple, pour identifier les cibles de mise à niveau valides pour une instance de base de données MySQL version 8.0.28, exécutez la commande suivante : AWS CLI
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mysql \
--engine-version 8.0.28 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mysql ^
--engine-version 8.0.28 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# Numéros de version de MySQL
La séquence de numérotation des versions du moteur de base de données RDS for MySQL se présente sous la forme *major.minor.patch.YYYYMMDD* ou *major.minor.patch*, par exemple 8.0.33.R2.20231201 ou 5.7.44. Le format utilisé dépend de la version du moteur MySQL. Pour en savoir plus sur la numérotation des versions de RDS Extended Support, consultez [Dénomination des versions du support étendu Amazon RDS](extended-support-versions.md#extended-support-naming).
**major**
Le numéro de version majeure est à la fois l’entier et la première partie fractionnaire du numéro de version, par exemple 8.0. Une mise à niveau majeure augmente la partie majeure du numéro de version. Par exemple, une mise à niveau de la version *5.7*.44 vers la version 8.0.33 est une mise à niveau de version majeure, *5.7* et *8.0* étant les numéros des versions majeures.
**mineure**
Le numéro de version mineure est la troisième partie du numéro de version, par exemple le 33 dans 8.0.33.
**patch**
Le correctif est la quatrième partie du numéro de version, par exemple R2 dans 8.0.33.R2. Une version de correctif RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication.
**YYYYMMDD**
La date est la cinquième partie du numéro de version, par exemple 20231201 dans 8.0.33.R2.20231201. Une version avec date RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication. Elle n’inclut aucun correctif susceptible de modifier le comportement d’un moteur.
Le tableau suivant explique le schéma de dénomination pour RDS for MySQL version 8.4.
| Version mineure 8.4 | Schéma de dénomination |
| --- | --- |
| ≥ 3 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 8.4.3.R2.20241201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 8.4.3.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
Le tableau suivant explique le schéma de dénomination pour RDS for MySQL version 8.0.
| Version mineure 8.0 | Schéma de dénomination |
| --- | --- |
| ≥ 33 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 8.0.33.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 8.0.33.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
| < 33 | Les instances de base de données existantes utilisent *major.minor.patch*, par exemple 8.0.32.R2. |
Le tableau suivant explique le schéma de dénomination pour RDS for MySQL version 5.7.
| Version mineure 5.7 | Schéma de dénomination |
| --- | --- |
| ≥ 42 | Les nouvelles instances de base de données utilisent *major.minor.patch.YYMMDD*, par exemple 5.7.42.R2.20231201. Les instances de base de données existantes peuvent utiliser *major.minor.patch*, par exemple 5.7.42.R2, jusqu’à votre prochaine mise à niveau de version majeure ou mineure. |
# Numéros de version RDS dans RDS for MySQL
Les numéros de version de RDS utilisent le schéma de dénomination `major.minor.patch` ou `major.minor.patch.YYYYMMDD`. Les versions d'Amazon RDS Extended Support utilisent le schéma de dénomination *minor-RDS.YYYYMMDD* des versions secondaires.
Une version de correctif RDS inclut des corrections de bogues importantes apportées à une version mineure après sa publication. Une version de date RDS (*YYYYMMDD*) est un correctif de sécurité. Un correctif de sécurité n’inclut aucun correctif susceptible de modifier le comportement du moteur. Pour en savoir plus sur la numérotation des versions de RDS Extended Support, consultez [Dénomination des versions du support étendu Amazon RDS](extended-support-versions.md#extended-support-naming).
Vous pouvez connaître le numéro de version RDS de votre base de données RDS for MySQL avec la requête SQL suivante :
```
mysql> select mysql.rds_version();
```
Par exemple, l’interrogation d’une base de données RDS for MySQL 8.0.34 renvoie ce qui suit :
```
+---------------------+
| mysql.rds_version() |
+---------------------+
| 8.0.34.R2.20231201 |
+---------------------+
1 row in set (0.01 sec)
```
# Mises à niveau des versions majeures pour RDS for MySQL
Amazon RDS prend en charge les mises à niveau sur place des versions majeures suivantes du moteur de base de données MySQL :
+ MySQL 5.7 vers MySQL 8.0
+ MySQL 8.0 vers MySQL 8.4
**Note**
Vous pouvez uniquement créer des instances de base de données MySQL versions 5.7, 8.0 et 8.4 avec les classes d’instance de base de données de la génération actuelle et de la dernière génération.
Dans certains cas, vous souhaiterez mettre à niveau une instance de base de données en cours d’exécution sur une classe d’instance de base de données de génération précédente vers une instance de base de données avec une version supérieure de moteur MySQL. Dans ce cas, commencez par modifier l’instance de base de données afin d’utiliser une classe d’instance de base de données de génération actuelle ou de dernière génération. Ensuite, vous pouvez modifier l’instance de base de données pour utiliser la version supérieure de moteur de base de données MySQL. Pour plus d’informations sur les classes d’instance de base de données Amazon RDS, consultez [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
**Topics**
+ [
## Présentation des mises à niveau de version majeure MySQL
](#USER_UpgradeDBInstance.MySQL.Major.Overview)
+ [
## Vérifications préalables pour les mises à niveau
](#USER_UpgradeDBInstance.MySQL.Prechecks)
+ [
## Annulation après échec de la mise à niveau
](#USER_UpgradeDBInstance.MySQL.Major.RollbackAfterFailure)
## Présentation des mises à niveau de version majeure MySQL
Les mises à niveau de version majeure peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. En conséquence, Amazon RDS n’applique pas automatiquement les mises à niveau de version majeure. Vous devez modifier manuellement votre instance de base de données. Nous vous recommandons de tester soigneusement toute mise à niveau avant de l'appliquer à vos instances de production.
Pour effectuer une mise à niveau de version majeure, procédez d’abord aux mises à jour du système d’exploitation disponibles. Une fois les mises à jour du système d’exploitation terminées, mettez à niveau vers chaque version majeure : 5.7 vers 8.0, puis 8.0 vers 8.4. Pour en savoir plus sur la mise à niveau d’un cluster de bases de données multi-AZ RDS for MySQL, consultez [Mise à niveau de la version du moteur d’un cluster de bases de données multi-AZ pour Amazon RDS](multi-az-db-clusters-upgrading.md). Les instances de base de données MySQL créées avant le 24 avril 2014 affichent une mise à jour de système d’exploitation disponible jusqu’à ce que celle-ci soit appliquée. Pour plus d’informations sur les mises à jour du système d’exploitation, consultez [Appliquer des mises à jour à un d'instances de base de données](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades).
Au cours d’une mise à niveau de version majeure de MySQL, Amazon RDS exécute le fichier binaire MySQL `mysql_upgrade` pour mettre à niveau les tables, si nécessaire. Amazon RDS vide également les tables `slow_log` et `general_log` pendant une mise à niveau de version majeure. Pour conserver les informations de journal, enregistrez le contenu du journal avant la mise à niveau de version majeure.
Les mises à niveau des versions majeures de MySQL durent généralement environ 10 minutes. Certaines mises à niveau peuvent durer plus longtemps en raison de la taille de la classe d’instance de base de données ou parce que l’instance ne suit pas certaines directives opérationnelles indiquées dans [Bonnes pratiques relatives à Amazon RDS.](CHAP_BestPractices.md). Si vous effectuez une mise à niveau d’une instance de base de données à partir de la console Amazon RDS, le statut de l’instance de base de données indique quand la mise niveau est terminée. Si vous effectuez la mise à niveau à l'aide de AWS Command Line Interface (AWS CLI), utilisez la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande et vérifiez la `Status` valeur.
## Vérifications préalables pour les mises à niveau
Amazon RDS effectue des vérifications préalables avant la mise à niveau afin de vérifier les incompatibilités. Ces incompatibilités varient en fonction de la version de MySQL vers laquelle la mise à niveau est effectuée.
Certaines vérifications préalables sont incluses avec MySQL et d’autres ont été spécifiquement créées par l’équipe Amazon RDS. Pour plus d’informations sur les vérifications préalables fournies par MySQL, consultez [Upgrade Checker Utility](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html).
Les vérifications préalables s’exécutent avant que l’instance de base de données soit arrêtée pour la mise à niveau, ce qui signifie que leur exécution n’entraîne aucune durée d’indisponibilité. Si les vérifications préalables trouvent une incompatibilité, Amazon RDS annule automatiquement la mise à niveau avant que l’instance de base de données soit arrêtée. Amazon RDS génère également un événement pour l’incompatibilité. Pour plus d’informations sur les événements Amazon RDS, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
Amazon RDS enregistre des informations détaillées sur chaque incompatibilité dans le fichier journal `PrePatchCompatibility.log`. Dans la plupart des cas, l’entrée de journal inclut un lien vers la documentation MySQL permettant de corriger l’incompatibilité. Pour plus d’informations sur l’affichage des fichiers journaux, consultez [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md).
En raison de la nature des vérifications préalables, elles analysent les objets dans votre base de données. L’analyse entraîne la consommation de ressources et augmente le temps nécessaire pour la mise à niveau.
**Topics**
+ [
### Vérifications préalables aux mises à jour de MySQL 8.0 vers 8.4
](#USER_UpgradeDBInstance.MySQL.80to84Prechecks)
+ [
### Vérifications préalables aux mises à jour de MySQL 5.7 vers 8.0
](#USER_UpgradeDBInstance.MySQL.57to80Prechecks)
### Vérifications préalables aux mises à jour de MySQL 8.0 vers 8.4
MySQL 8.4 inclut plusieurs incompatibilités avec MySQL 8.0. Ces incompatibilités peuvent provoquer des problèmes lors d’une mise à niveau de MySQL 8.0 vers MySQL 8.4. Une certaine préparation est donc nécessaire sur votre base de données pour garantir la réussite de la mise à niveau. La liste suivante est une liste généralisée de ces incompatibilités :
+ Les tables ne doivent pas utiliser de fonctions ou de types de données obsolètes.
+ Les déclencheurs ne doivent pas avoir de definer manquant ou vide, ni de contexte de création invalide.
+ Il ne doit y avoir aucune violation de mot clé ou de mot réservé. Certains mots clés doivent être réservés dans MySQL 8.4 alors qu’ils ne l’étaient pas par le passé.
Pour en savoir plus, consultez [Mots clés et mots réservés](https://dev.mysql.com/doc/refman/8.4/en/keywords.html) dans la documentation MySQL.
+ Aucune table de la base de données du système `mysql` dans MySQL 8.0 ne doit avoir le même nom que la table utilisée dans le dictionnaire de données MySQL 8.4.
+ Aucun mode SQL obsolète ne doit être défini dans la configuration variable de votre système `sql_mode`.
+ Aucune table ni procédure stockée avec des éléments de colonne `ENUM` ou `SET` individuels ne doit dépasser 255 caractères ou 1 020 octets de longueur.
+ Votre installation MySQL 8.0 ne doit pas utiliser de fonctionnalités incompatibles avec MySQL 8.4.
Pour plus d’informations, consultez [Fonctionnalités supprimées dans MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html#mysql-nutshell-removals) dans la documentation MySQL.
+ Aucun nom de contrainte de clé étrangère ne doit dépasser 64 caractères.
+ Pour une prise en charge Unicode améliorée, consultez les informations suivantes :
+ Envisagez de convertir les objets qui utilisent le jeu de caractères `utf8mb3` pour utiliser le jeu de caractères `utf8mb4`. Le jeu de caractères `utf8mb3` est obsolète.
+ Envisagez d’utiliser `utf8mb4` pour référencer les jeux de caractères au lieu de `utf8`. En effet, actuellement, `utf8` est un alias du jeu de caractères `utf8mb3`. Si possible, passez d’abord de `utf8mb4` à `utf8`, puis mettez à niveau votre base de données.
+ Comme les clients plus anciens peuvent recevoir une erreur de jeu de caractères inconnue pour `utf8mb3`, mettez à niveau vos clients de base de données avant de mettre à niveau votre base de données.
Pour en savoir plus, consultez [ Le jeu de caractères utf8mb3 (encodage Unicode 3 octets en UTF-8)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) dans la documentation MySQL.
Pour modifier les jeux de caractères, vous pouvez effectuer manuellement une sauvegarde, une restauration et une réplication de votre base de données. Vous pouvez également utiliser Amazon RDS Blue/Green Deployments. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
Lorsque vous démarrez une mise à niveau de MySQL 8.0 vers 8.4, Amazon RDS exécute automatiquement des vérifications préalables pour détecter ces incompatibilités. Pour plus d’informations sur la mise à niveau vers MySQL 8.4, consultez [Upgrading MySQL](https://dev.mysql.com/doc/refman/8.4/en/upgrading.html) dans la documentation MySQL.
Ces vérifications préalables sont obligatoires. Vous ne pouvez pas choisir de les ignorer. Elles offrent les avantages suivants :
+ Elles vous permettent d’éviter les durées d’indisponibilités non planifiées pendant la mise à niveau.
+ Si vous avez des incompatibilités, Amazon RDS empêche la mise à niveau et vous fournit un journal pour que vous en sachiez plus à leur sujet. Vous pouvez ensuite utiliser le journal pour préparer votre base de données pour la mise à niveau vers la version 8.4 de MySQL en réduisant ces incompatibilités. Pour obtenir des informations détaillées sur la suppression des incompatibilités, consultez [Préparation de votre installation pour la mise à niveau](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) dans la documentation MySQL.
### Vérifications préalables aux mises à jour de MySQL 5.7 vers 8.0
MySQL 8.0 inclut plusieurs incompatibilités avec MySQL 5.7. Ces incompatibilités peuvent provoquer des problèmes lors d’une mise à niveau de MySQL 5.7 vers MySQL 8.0. Une certaine préparation est donc nécessaire sur votre base de données pour garantir la réussite de la mise à niveau. La liste suivante est une liste généralisée de ces incompatibilités :
+ Les tables ne doivent pas utiliser de fonctions ou de types de données obsolètes.
+ Il ne doit y avoir aucun fichier \$1.frm orphelin.
+ Les déclencheurs ne doivent pas avoir de definer manquant ou vide, ni de contexte de création invalide.
+ Aucune table partitionnée ne doit utiliser de moteur de stockage dépourvu de prise en charge native du partitionnement.
+ Il ne doit y avoir aucune violation de mot clé ou de mot réservé. Certains mots clés doivent être réservés dans MySQL 8.0 alors qu’ils ne l’étaient pas par le passé.
Pour en savoir plus, consultez [Mots clés et mots réservés](https://dev.mysql.com/doc/refman/8.0/en/keywords.html) dans la documentation MySQL.
+ Aucune table de la base de données du système `mysql`dans MySQL 5.7 ne doit avoir le même nom que la table utilisée dans le dictionnaire de données MySQL 8.0.
+ Aucun mode SQL obsolète ne doit être défini dans la configuration variable de votre système `sql_mode`.
+ Aucune table ni procédure stockée avec des éléments de colonne `ENUM` ou `SET` individuels ne doit dépasser 255 caractères ou 1 020 octets de longueur.
+ Avant de mettre à niveau vers la version MySQL 8.0.13 ou une version ultérieure, aucune partition de table ne doit se trouver dans les espaces de stockage InnoDB partagés.
+ Aucune requête ni définition de programme de la version MySQL 8.0.12 ou d’une version antérieure ne doit utiliser de qualificateur `ASC` ou `DESC` pour les clauses `GROUP BY`.
+ Votre installation MySQL ne doit pas utiliser de fonctionnalités incompatibles avec MySQL 8.0.
Pour plus d’informations, consultez [Fonctionnalités supprimées dans MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) dans la documentation MySQL.
+ Aucun nom de contrainte de clé étrangère ne doit dépasser 64 caractères.
+ Pour une prise en charge Unicode améliorée, consultez les informations suivantes :
+ Envisagez de convertir les objets qui utilisent le jeu de caractères `utf8mb3` pour utiliser le jeu de caractères `utf8mb4`. Le jeu de caractères `utf8mb3` est obsolète.
+ Envisagez d’utiliser `utf8mb4` pour référencer les jeux de caractères au lieu de `utf8`. En effet, actuellement, `utf8` est un alias du jeu de caractères `utf8mb3`. Si possible, passez d’abord de `utf8mb4` à `utf8`, puis mettez à niveau votre base de données.
+ Comme les clients plus anciens peuvent recevoir une erreur de jeu de caractères inconnue pour `utf8mb3`, mettez à niveau vos clients de base de données avant de mettre à niveau votre base de données.
Pour en savoir plus, consultez [ Le jeu de caractères utf8mb3 (encodage Unicode 3 octets en UTF-8)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) dans la documentation MySQL.
Pour modifier les jeux de caractères, vous pouvez effectuer manuellement une sauvegarde, une restauration et une réplication de votre base de données. Vous pouvez également utiliser Amazon RDS Blue/Green Deployments. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
Lorsque vous démarrez une mise à niveau de MySQL 5.7 vers 8.0, Amazon RDS exécute automatiquement des vérifications préalables pour détecter ces incompatibilités. Pour plus d’informations sur la mise à niveau vers MySQL 8.0, consultez [Upgrading MySQL](https://dev.mysql.com/doc/refman/8.0/en/upgrading.html) dans la documentation MySQL.
Ces vérifications préalables sont obligatoires. Vous ne pouvez pas choisir de les ignorer. Elles offrent les avantages suivants :
+ Elles vous permettent d’éviter les durées d’indisponibilités non planifiées pendant la mise à niveau.
+ Si vous avez des incompatibilités, Amazon RDS empêche la mise à niveau et vous fournit un journal pour que vous en sachiez plus à leur sujet. Vous pouvez ensuite utiliser le journal pour préparer votre base de données pour la mise à niveau vers la version 8.0 de MySQL en réduisant ces incompatibilités. Pour obtenir des informations détaillées sur la suppression des incompatibilités, consultez [Préparation de votre installation pour la mise à niveau](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) (langue française non garantie) dans la documentation MySQL et [Mise à niveau vers MySQL 8.0 ? Ce que vous devez savoir…](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) (langue française non garantie) sur le blog MySQL Server.
## Annulation après échec de la mise à niveau
Lorsque vous mettez à niveau une instance de base de données de MySQL version 5.7 vers MySQL version 8.0 ou de MySQL version 8.0 vers 8.4, la mise à niveau peut échouer. Elle peut échouer en particulier si le dictionnaire de données contient des incompatibilités qui n’ont pas été détectées alors des vérifications préalables. Dans ce cas, la base de données ne parvient pas à démarrer dans la nouvelle version de MySQL 8.0 ou 8.4. À ce stade, Amazon RDS annule les modifications effectuées pour la mise à niveau. Après la restauration, l’instance de base de données MySQL exécute la version d’origine.
+ MySQL version 8.0 (pour une restauration à MySQL 8.4)
+ MySQL version 5.7 (pour une restauration à MySQL 8.0)
Lorsqu’une mise à niveau échoue et qu’elle est annulée, Amazon RDS génère un événement avec l’ID RDS-EVENT-0188.
Généralement, une mise à niveau échoue car il existe des incompatibilités dans les métadonnées entre les bases de données de votre instance de base de données et la version MySQL cible. En cas d’échec d’une mise à niveau, vous pouvez afficher les détails de ces incompatibilités dans le fichier `upgradeFailure.log`. Vous devez résoudre les incompatibilités avant de répéter la tentative de mise à niveau.
Lors d’une tentative de mise à niveau infructueuse et d’une restauration, votre instance de base de données est redémarrée. Tous les changements de paramètres en attente sont appliqués lors du redémarrage et sont maintenus après la restauration.
Pour plus d’informations sur la mise à niveau vers MySQL 8.0, consultez les rubriques suivantes de la documentation MySQL :
+ [ Préparation de votre installation pour la mise à niveau ](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html)
+ [Mettre à niveau vers MySQL 8.0 ? Voici ce que vous devez savoir…](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/)
Pour en savoir plus sur mise à niveau vers MySQL 8.4, consultez [Préparation de votre installation pour la mise à niveau](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) dans la documentation MySQL.
# Test d’une mise à niveau de RDS for MySQL
Avant d’effectuer une mise à niveau de version majeure sur votre instance de base de données, testez soigneusement la compatibilité de votre base de données avec la nouvelle version. En outre, vous devez tester soigneusement la compatibilité de toutes les applications qui accèdent à la base de données avec la nouvelle version. Nous vous recommandons d’utiliser la procédure suivante.
**Pour tester une mise à niveau de version majeure**
1. Passez en revue la documentation de la mise à niveau pour la nouvelle version du moteur de base de données afin de voir si des problèmes de compatibilité peuvent affecter votre base de données ou vos applications :
+ [Changements dans MySQL 5.7](http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html)
+ [Changements dans MySQL 8.0](http://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)
+ [Changements dans MySQL 8.4](http://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html)
1. Si votre instance de base de données est membre d’un groupe de paramètres de base de données personnalisé, créez un nouveau groupe de paramètres de base de données avec vos paramètres existants, qui soit compatible avec la nouvelle version majeure. Spécifiez le nouveau groupe de paramètres de base de données lorsque vous mettez à niveau votre instance de test afin que les tests de mise à niveau puissent vérifier son bon fonctionnement. Pour plus d’informations sur la création d’un groupe de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Créez un instantané de base de données de l’instance de base de données à mettre à niveau. Pour plus d’informations, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
1. Restaurez l’instantané de base de données pour créer une nouvelle instance de base de données de test. Pour plus d’informations, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
1. Modifiez cette nouvelle instance de base de données de test pour la mettre à niveau vers la nouvelle version, en utilisant l’une des méthodes détaillées plus loin. Si vous avez créé un groupe de paramètres à l’étape 2, spécifiez ce groupe de paramètres.
1. Évaluez le stockage utilisé par l’instance mise à niveau pour déterminer si la mise à niveau requiert un stockage supplémentaire.
1. Exécutez sur l’instance de base de données mise à niveau autant de tests d’assurance qualité que nécessaire pour garantir que votre base de données et votre application fonctionnent correctement avec la nouvelle version. Implémentez tous les nouveaux tests requis pour évaluer l’impact des éventuels problèmes de compatibilité que vous avez identifiés à l’étape 1. Testez toutes les fonctions et procédures stockées. Dirigez les versions de test de vos applications vers l’instance de base de données mise à niveau.
1. En cas de succès de tous les tests, effectuez la mise à niveau sur votre instance de base de données de production. Nous vous recommandons de ne pas autoriser les opérations d’écriture sur l’instance de base de données tant que vous n’avez pas confirmé que tout fonctionne correctement.
## Mise à niveau d'une instance de base de données MySQL
Pour plus d’informations sur la mise à niveau manuelle ou automatique d’une instance de base de données MySQL, consultez [Mise à niveau d'une version du moteur d'une instance de base de données](USER_UpgradeDBInstance.Upgrading.md).
# Mises à niveau automatiques des versions mineures pour RDS for MySQL
Si vous spécifiez les paramètres suivants lors de la création ou de la modification d’une instance de base de données, celle-ci peut être mise à niveau automatiquement.
+ Le paramètre **Mise à niveau automatique des versions mineures** est activé.
+ Le paramètre **Période de conservation des sauvegardes** est supérieur à 0.
Dans AWS Management Console, ces paramètres se trouvent sous **Additional configuration** (Configuration supplémentaire). L’image suivante illustre le réglage **Auto minor version upgrade** (Mise à niveau automatique de versions mineures).
![\[La section Maintenance avec Activer la mise à niveau automatique des versions mineures sélectionnée dans la console Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/amvu.png)
Pour plus d’informations sur ces paramètres, consultez la page [Paramètres des instances de base de données](USER_ModifyInstance.Settings.md).
Pour certaines versions majeures de RDS for MySQL dans certaines Régions AWS, RDS désigne une version mineure comme version de mise à niveau automatique. Une fois qu’une version mineure a été testée et approuvée par Amazon RDS, la mise à niveau de version mineure se produit automatiquement pendant votre fenêtre de maintenance. RDS ne définit pas automatiquement les dernières versions mineures publiées comme version de mise à niveau automatique. Avant de désigner une publication de version récente comme version de mise à niveau automatique, RDS prend en compte plusieurs critères, à savoir :
+ Problèmes de sécurité connus
+ Bogues dans la version de la communauté MySQL
+ Stabilité globale de la flotte depuis la publication de la version mineure
Vous pouvez utiliser la commande AWS CLI suivante pour déterminer la version cible de mise à niveau automatique mineure actuelle pour une version mineure spécifiée de MySQL dans une Région AWS spécifique.
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mysql \
--engine-version minor_version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mysql ^
--engine-version minor_version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
Par exemple, la commande AWS CLI suivante détermine la cible de mise à niveau mineure automatique pour la version mineure 8.0.11 de MySQL dans la Région AWS USA Est (Ohio) (us-east-2).
Pour Linux, macOS ou Unix :
```
aws rds describe-db-engine-versions \
--engine mysql \
--engine-version 8.0.11 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Pour Windows :
```
aws rds describe-db-engine-versions ^
--engine mysql ^
--engine-version 8.0.11 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
Votre sortie est similaire à ce qui suit.
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 8.0.15 |
| False | 8.0.16 |
| False | 8.0.17 |
| False | 8.0.19 |
| False | 8.0.20 |
| False | 8.0.21 |
| True | 8.0.23 |
| False | 8.0.25 |
+--------------+-----------------+
```
Dans cet exemple, la valeur de `AutoUpgrade` est `True` pour MySQL version 8.0.23. Ainsi, la cible de mise à niveau mineure automatique est la version 8.0.23 de MySQL, comme indiqué dans la sortie.
Une instance de base de données MySQL est automatiquement mise à niveau pendant votre fenêtre de maintenance si les critères suivants sont réunis :
+ Le paramètre **Mise à niveau automatique des versions mineures** est activé.
+ Le paramètre **Période de conservation des sauvegardes** est supérieur à 0.
+ L’instance de base de données exécute une version mineure du moteur de base de données qui est inférieure à la version mineure de la mise à niveau automatique actuelle.
Pour plus d’informations, consultez [Mise à niveau automatique de la version mineure du moteur](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades).
# Utilisation d’un réplica en lecture pour réduire la durée d’indisponibilité lors de la mise à niveau d’une base de données RDS for MySQL
Dans la plupart des cas, un déploiement bleu/vert est la meilleure option pour réduire la durée d’indisponibilité lors de la mise à niveau d’une instance de base de données MySQL. Pour plus d’informations, consultez [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
Si vous ne pouvez pas utiliser un déploiement bleu/vert et que votre instance de base de données MySQL est en cours d’utilisation avec une application de production, vous pouvez utiliser la procédure suivante pour mettre à niveau la version de la base de données pour votre instance de base de données. Cette procédure peut réduire la durée d’indisponibilité de votre application.
En utilisant un réplica en lecture, vous pouvez effectuer la plupart des étapes de maintenance à l’avance et ainsi réduire les modifications nécessaires lors d’une panne réelle. Cette technique vous permet de tester et de préparer la nouvelle instance de base de données sans apporter de modifications à votre instance de base de données existante.
La procédure suivante illustre un exemple de mise à niveau de MySQL version 5.7 vers MySQL version 8.0. Vous pouvez utiliser les mêmes étapes générales pour des mises à niveau vers d’autres versions majeures. Vous pouvez utiliser les mêmes étapes générales pour des mises à niveau vers d’autres versions majeures.
**Note**
Avant de procéder à une mise à niveau de MySQL version 5.7 vers MySQL version 8.0 ou de MySQL version 8.0 vers MySQL version 8.4, quelques vérifications sont nécessaires. Pour plus d’informations, consultez [Vérifications préalables aux mises à jour de MySQL 5.7 vers 8.0](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.57to80Prechecks) et [Vérifications préalables aux mises à jour de MySQL 8.0 vers 8.4](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.80to84Prechecks).
**Pour mettre à niveau une base de données MySQL alors qu’une instance de base de données est en cours d’utilisation**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Créez un réplica en lecture de votre instance de base de données MySQL 5.7. Ce processus crée une copie pouvant être mise à niveau de votre base de données. D’autres réplicas en lecture de l’instance de base de données peuvent également exister.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez l’instance de base de données que vous souhaitez mettre à niveau.
1. Sous **Actions**, choisissez **Créer des réplicas en lecture**.
1. Spécifiez une valeur dans le champ **Identifiant de l’instance de base de données** de votre réplica en lecture et assurez-vous que la **Classe d’instance de base de données** et les autres paramètres correspondent à votre instance de base de données MySQL 5.7.
1. Choisissez **Créer un réplica en lecture**.
1. (Facultatif) Lorsque le réplica en lecture a été créé et que le champ **État** indique **Disponible**, convertissez le réplica en lecture en déploiement multi-AZ et activez les sauvegardes.
Par défaut, les sauvegardes désactivées quand un réplica en lecture est créé. Dans la mesure où le réplica en lecture finira par devenir l’instance de base de données de production, nous vous recommandons de configurer un déploiement multi-AZ et d’activer les sauvegardes.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de créer.
1. Sélectionnez **Modifier**.
1. Dans le champ **Déploiement multi-AZ**, choisissez **Créer une instance de secours**.
1. Dans le champ **Backup Retention Period** (Période de rétention des sauvegardes), choisissez une valeur positive différente de zéro (par exemple, 3 jours), puis sélectionnez **Continue** (Continuer).
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance DB**.
1. Lorsque le champ **État** du réplica en lecture indique **Disponible**, procédez à sa mise à niveau vers MySQL 8.0 :
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de créer.
1. Sélectionnez **Modifier**.
1. Dans le champ **Version du moteur de base de données**, choisissez la version de MySQL 8.0 vers laquelle vous souhaitez effectuer la mise à niveau, puis sélectionnez **Continuer**.
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance de base de données** pour démarrer la mise à niveau.
1. Lorsque la mise à niveau est terminée et que le champ **État** indique **Disponible**, vérifiez que le réplica en lecture mis à niveau est à jour avec l’instance de base de données MySQL 5.7 source. Pour vérifier, connectez-vous au réplica en lecture et exécutez la commande `SHOW REPLICA STATUS`. Si le champ `Seconds_Behind_Master` a pour valeur `0`, la réplication est à jour.
**Note**
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`.
1. (Facultatif) Créez un réplica en lecture de votre réplica en lecture.
Si vous souhaitez que l’instance de base de données dispose d’un réplica en lecture une fois celle-ci promue en tant qu’instance de base de données autonome, vous pouvez créer le réplica en lecture dès maintenant.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de mettre à niveau.
1. Sous **Actions**, choisissez **Créer des réplicas en lecture**.
1. Spécifiez une valeur dans le champ **Identifiant de l’instance de base de données** de votre réplica en lecture et assurez-vous que la **Classe d’instance de base de données** et les autres paramètres correspondent à votre instance de base de données MySQL 5.7.
1. Choisissez **Créer un réplica en lecture**.
1. (Facultatif) Configurez un groupe de paramètres de base de données personnalisé pour le réplica en lecture.
Si vous souhaitez que l’instance de base de données utilise un groupe de paramètres personnalisé une fois celle-ci promue en tant qu’instance de base de données autonome, vous pouvez créer le groupe de paramètres de base de données dès maintenant et l’associer au réplica en lecture.
1. Créez un groupe de paramètres de base de données personnalisé pour MySQL 8.0. Pour obtenir des instructions, consultez [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md).
1. Modifiez les paramètres que vous souhaitez modifier dans le groupe de paramètres de base de données fraîchement créé. Pour obtenir des instructions, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture.
1. Sélectionnez **Modifier**.
1. Dans le champ **Groupe de paramètres de base de données**, choisissez le groupe de paramètres de base de données MySQL 8.0 que vous venez de créer, puis sélectionnez **Continuer**.
1. Pour **Planification des modifications**, choisissez **Appliquer immédiatement**.
1. Choisissez **Modifier l’instance de base de données** pour démarrer la mise à niveau.
1. Faites de votre réplica en lecture MySQL 8.0 une instance de base de données autonome.
**Important**
Une fois promu en tant qu’instance de base de données autonome, votre réplica en lecture MySQL 8.0 cesse d’être un réplica de votre instance de base de données MySQL 5.7. Nous vous conseillons d’effectuer la promotion de votre réplica en lecture MySQL 8.0 au cours d’un créneau de maintenance, lorsque votre instance de base de données MySQL 5.7 source est en mode lecture seule et que toutes les opérations d’écriture sont suspendues. Au terme de l’opération de promotion, vous pouvez diriger vos opérations d’écriture vers l’instance de base de données MySQL 8.0 mise à niveau pour veiller à ce qu’aucune opération d’écriture ne se perde.
En outre, avant la promotion de votre réplica en lecture MySQL 8.0, nous vous conseillons d’effectuer toutes les opérations DDL (Data Definition Language) nécessaires sur votre réplica en lecture MySQL 8.0. Par exemple, la création d’index. Cette approche permet d’éviter tout effet négatif sur les performances du réplica en lecture MySQL 8.0 après sa promotion. Pour promouvoir un réplica en lecture.
1. Sur la console, choisissez **Bases de données**, puis sélectionnez le réplica en lecture que vous venez de mettre à niveau.
1. Pour **Actions**, choisissez **Promote (Promouvoir)**.
1. Choisissez **Oui** pour activer les sauvegardes automatiques pour l’instance du réplica en lecture. Pour plus d’informations, consultez [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
1. Choisissez **Continuer**.
1. Choisissez **Promouvoir le réplica en lecture**.
1. Vous disposez à présent d’une version mise à niveau de votre base de données MySQL. À ce stade, vous pouvez diriger vos applications vers la nouvelle instance de base de données MySQL 8.0.
# Surveillance des mises à niveau du moteur RDS for MySQL à l'aide d'événements
Lorsque vous mettez à niveau la version du moteur d'une base de données RDS pour MySQL, Amazon RDS émet un événement spécifique à chaque phase du processus. Pour suivre la progression d'une mise à niveau, vous pouvez consulter ces événements ou vous y abonner.
Pour plus d'informations sur les événements RDS, consultez[Surveillance des événements Amazon RDS](working-with-events.md).
Pour obtenir des informations détaillées sur un événement Amazon RDS spécifique qui se produit lors de la mise à niveau de votre moteur, consultez[Catégories d'événements Amazon RDS et messages d'événements ](USER_Events.Messages.md).
# Mise à niveau d’une version du moteur d’instantané de base de données MySQL
Amazon RDS vous permet de créer un instantané de base de données de volume de stockage de votre instance de base de données MySQL. Lorsque vous créez un instantané de base de données, l’instantané est basé sur la version du moteur utilisée par votre instance de base de données. Vous pouvez mettre à niveau la version du moteur pour vos instantanés de base de données.
Pour RDS for MySQL, vous pouvez mettre à niveau un instantané de la version 5.7 vers la version 8.0, ou un instantané de la version 8.0 vers la version 8.4. Vous pouvez mettre à niveau des instantanés de base de données chiffrés ou non chiffrés.
Pour afficher les versions de moteur disponibles pour votre instantané de base de données RDS for MySQL, utilisez l’exemple AWS CLI suivant.
```
aws rds describe-db-engine-versions --engine mysql --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Si vous ne voyez aucun résultat pour votre instantané, la version de votre moteur est peut-être obsolète. Si la version de votre moteur est obsolète, nous vous recommandons d’effectuer une mise à niveau vers la cible de mise à niveau de la version majeure la plus récente ou vers l’une des autres cibles de mise à niveau disponibles pour cette version. Pour de plus amples informations, veuillez consulter [Mise à niveau des options pour les instantanés de base de données avec des versions de moteur non prises en charge pour RDS for MySQL](mysql-upgrade-snapshot.upgrade-options.md).
Après avoir restauré un instantané de base de données mis à niveau vers une nouvelle version de moteur, veillez à vérifier que la mise à jour est réussie. Pour plus d’informations sur une mise à niveau des versions majeures, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md). Pour savoir comment restaurer un instantané de base de données, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
**Note**
Vous ne pouvez pas mettre à niveau des instantanés de base de données automatisés qui ont été créés lors du processus de sauvegarde automatique.
Vous pouvez mettre à niveau un instantané de base de données à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
------
#### [ Console ]
Pour mettre à niveau une version du moteur de snapshots de base de données à l'aide de AWS Management Console, procédez comme suit.
**Pour mettre à niveau un instantané de base de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Snapshots**.
1. Choisissez l’instantané que vous souhaitez mettre à niveau.
1. Pour **Actions**, choisissez **Upgrade Snapshot (Mettre à niveau l’instantané)**. La page **Upgrade Snapshot (Mettre à niveau l’instantané)** s’affiche.
1. Choisissez la **New engine version (Version du nouveau moteur)** vers laquelle mettre à niveau.
1. Choisissez **Save changes (Enregistrer les changements)** pour mettre à niveau l’instantané.
Pendant le processus de mise à niveau, toutes les actions d’instantané sont désactivées pour l’instantané de base de données. De même, le statut de l’instantané de base de données passe de **Disponible** à **Mise à niveau**, puis passe à **Actif** une fois la mise à niveau terminée. Si l’instantané de base de données ne peut pas être mis à jour en raison d’un problème d’instantané endommagé, le statut devient **Indisponible**. Vous ne pouvez pas récupérer l’instantané lorsqu’il a ce statut.
**Note**
Si la mise à niveau de l’instantané de base de données échoue, l’instantané revient à l’état d’origine avec la version originale.
------
#### [ AWS CLI ]
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, exécutez la AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)commande.
**Options**
+ `--db-snapshot-identifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `--engine-version` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-snapshot \
2.
3. --db-snapshot-identifier my_db_snapshot \
4. --engine-version new_version
```
Pour Windows :
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
------
#### [ Amazon RDS API ]
Pour mettre à niveau un instantané de base de données vers une nouvelle version du moteur de base de données, appelez l'DBSnapshotopération RDS API [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html).
**Parameters**
+ `DBSnapshotIdentifier` : l’identifiant de l’instantané de base de données à mettre à niveau. L’identifiant doit être unique pour un Amazon Resource Name (ARN). Pour plus d'informations, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
+ `EngineVersion` : la version du moteur vers laquelle la mise à niveau de l’instantané de base de données doit être effectuée.
------
# Mise à niveau des options pour les instantanés de base de données avec des versions de moteur non prises en charge pour RDS for MySQL
Le tableau suivant indique les versions de moteur vers lesquelles vous pouvez effectuer une mise à niveau à partir d’une version de moteur non prise en charge pour les instantanés de base de données RDS for MySQL.
**Note**
Il se peut que vous deviez mettre à niveau votre instantané de base de données plusieurs fois pour passer à la version du moteur que vous avez choisie.
| Version du moteur d’instantané de base de données | Versions du moteur disponibles pour la mise à niveau |
| --- | --- |
| 5.5.8 | 5.5.62, 5.6.51 |
| 5,5,12 | 5.5.62, 5.6.51 |
| 5,5,20 | 5.5.62, 5.6.51 |
| 5,5,23 | 5.5.62, 5.6.51 |
| 5.5.25a | 5.5.62, 5.6.51 |
| 5,5,27 | 5.5.62, 5.6.51 |
| 5,5,31 | 5.5.62, 5.6.51 |
| 5,5,33 | 5.5.62, 5.6.51 |
| 5,5,37 | 5.5.62, 5.6.51 |
| 5,5,38 | 5.5.62, 5.6.51 |
| 5,5,40 | 5.5.62, 5.6.51 |
| 5.5.40a | 5.5.62, 5.6.51 |
| 5.5.40b | 5.5.62, 5.6.51 |
| 5,5,41 | 5.5.62, 5.6.51 |
| 5,5,42 | 5.5.62, 5.6.51 |
| 5.5.59 | 5.5.62, 5.6.51 |
| 5,6,12 | 5.6.51, 5.7.44 |
| 5,6,13 | 5.6.51, 5.7.44 |
| 5,6,17 | 5.6.51, 5.7.44 |
| 5,6,19 | 5.6.51, 5.7.44 |
| 5.6.19a | 5.6.51, 5.7.44 |
| 5.6.19b | 5.6.51, 5.7.44 |
| 5,6,21 | 5.6.51, 5.7.44 |
| 5.6.21b | 5.6.51, 5.7.44 |
| 5,6,22 | 5.6.51, 5.7.44 |
| 5,6,23 | 5.6.51, 5.7.44 |
| 5,6,27 | 5.6.51, 5.7.44 |
| 5.6.27a | 5.6.51, 5.7.44 |
| 5,7,10 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 |
| 5.7,11 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 |
| 5,7,12 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 |
# Importation de données dans une instance de base de données Amazon RDS for MySQL
Vous pouvez utiliser plusieurs techniques pour importer des données dans une instance de base de données RDS for MySQL. La meilleure approche dépend d’un certain nombre de facteurs :
+ Source des données
+ Quantité de données
+ Importation en une seule fois ou en continu
+ Durée d’indisponibilité
Si vous migrez également une application avec les données, tenez également compte de la durée d’indisponibilité que vous êtes prêt à accepter.
Le tableau suivant répertorie les techniques d’importation de données dans une instance de base de données RDS for MySQL :
| Source | Quantité de données | Une seule fois ou en continu | Interruption de l'application | Technique | En savoir plus |
| --- | --- | --- | --- | --- | --- |
| Base de données MySQL existante sur site ou sur Amazon EC2 | N'importe quel compte | Une seule fois | Momentanée | Créez une sauvegarde de votre base de données sur site, stockez-la sur Amazon S3, puis restituez le fichier de sauvegarde sur une nouvelle instance de base de données Amazon RDS exécutant MySQL. | [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md) |
| Base de données MySQL existante sur site ou sur Amazon EC2 | N’importe quel compte | En continu | Minimale | Configurez la réplication avec une base de données MySQL existante comme source de réplication. | [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md) [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) |
| Toute base de données existante | N'importe quel compte | Une seule fois ou en continu | Minimale | AWS Database Migration Service À utiliser pour migrer la base de données avec un temps d'arrêt minimal et, pour de nombreux moteurs de base de données, poursuivre la réplication continue. | [Présentation d' AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) et [Utilisation d'une base de données compatible MySQL comme cible pour AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) dans le *Guide de l'utilisateur AWS Database Migration Service * |
| Instance de base de données MySQL existante | N'importe quel compte | Une seule fois ou en continu | Minimale | Créez un réplica en lecture pour la réplication continue. Promouvez le réplica en lecture pour la création unique d’une nouvelle instance de base de données. | [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md) |
| Base de données MySQL existante | Petite | Une seule fois | Momentanée | Copiez les données directement dans votre instance de base de données MySQL à l'aide d'un utilitaire de ligne de commande. | [Importation de données à partir d’une base de données MySQL externe vers une instance de base de données Amazon RDS for MySQL](mysql-importing-data-external-database.md) |
| Données non stockées dans une base de données existante | Medium | Une seule fois | Momentanée | Créez des fichiers plats et importez-les à l’aide des instructions MySQL LOAD DATA LOCAL INFILE. | [Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MySQL](mysql-importing-data-any-source.md) |
**Note**
La base de données système `mysql` contient les informations d’authentification et d’autorisation requises pour se connecter à l’instance de base de données et accéder aux données. La suppression, la modification, le renommage ou la troncation de tables, de données ou d'autres contenus de la base de données `mysql` de votre instance de base de données peut produire une erreur et rendre inaccessibles l'instance de base de données et vos données. Dans ce cas, vous pouvez restaurer l'instance de base de données à partir d'un instantané à l'aide de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)commande. Vous pouvez récupérer l'instance de base de données à l'aide de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)commande.
# Considérations sur l’importation de données pour MySQL
Le contenu suivant présente des informations techniques sur le chargement de données dans MySQL. Ce contenu est destiné aux utilisateurs qui connaissent bien l’architecture de serveur MySQL.
## Journalisation binaire
L’activation de la journalisation binaire réduit les performances de chargement des données et nécessite jusqu’à quatre fois plus d’espace disque que la journalisation désactivée. La taille des transactions utilisées pour charger les données influe directement sur les performances du système et les besoins en espace disque. Les transactions plus importantes nécessitent davantage de ressources.
## Taille de la transaction
La taille des transactions influence les aspects suivants du chargement de données MySQL :
+ Consommation des ressources
+ Utilisation de l’espace disque
+ Reprendre le processus
+ Délai de récupération
+ Format d’entrée (fichiers plats ou SQL)
Cette section décrit comment la taille de la transaction influe sur la journalisation binaire. En outre, elle plaide en faveur de la désactivation de cette même journalisation lors de chargements de données volumineux. Vous pouvez activer et désactiver la journalisation binaire en définissant la période de rétention des sauvegardes automatiques Amazon RDS. Les valeurs différentes de zéro activent la journalisation binaire, tandis que la valeur zéro la désactive. Pour plus d’informations, consultez [Période de rétention des sauvegardes](USER_WorkingWithAutomatedBackups.BackupRetention.md).
Cette section décrit également l’impact des transactions volumineuses sur InnoDB et pourquoi il est important que les transactions conservent une petite taille.
### Petites transactions
Pour les petites transactions, la journalisation binaire multiplie par deux le nombre d'écritures sur disque requises pour charger les données. Elle peut ainsi affecter gravement les performances des autres sessions de base de données et accroître le temps requis pour charger les données. La dégradation subie dépend en partie des facteurs suivants :
+ Vitesse de chargement
+ Autres activités de base de données ayant lieu pendant le chargement
+ Capacité de votre instance de base de données Amazon RDS
Les journaux binaires consomment aussi un espace disque approximativement égal à la quantité de données chargées jusqu’à ce que les journaux soient sauvegardés et supprimés. Amazon RDS réduit cette consommation en sauvegardant et en supprimant fréquemment les journaux binaires.
### Transactions volumineuses
Pour les transactions importantes, la journalisation binaire triple les IOPS et l’utilisation du disque pour les raisons suivantes :
+ Le cache du journal binaire stocke temporairement les données de transaction sur le disque.
+ Ce cache augmente avec la taille de la transaction, ce qui consomme de l’espace disque.
+ Lorsque la transaction (validation ou annulation) est terminée, le système copie le cache dans le journal binaire.
Ce processus crée trois copies des données :
+ Les données d’origine
+ Le cache sur le disque
+ La dernière entrée du journal binaire
Chaque opération d’écriture entraîne des E/S supplémentaires, ce qui a un impact supplémentaire sur les performances.
De ce fait, la journalisation binaire nécessite trois fois plus d’espace disque que la journalisation désactivée. Par exemple, le chargement de 10 GiB de données en une seule transaction crée trois copies :
+ 10 GiB pour les données du tableau
+ 10 GiB pour le cache du journal binaire
+ 10 GiB pour le fichier journal binaire
L’espace disque temporaire total requis est de 30 GiB.
Considérations importantes relatives à l’espace disque :
+ Le fichier de cache est conservé jusqu’à la fin de la session ou jusqu’à ce qu’une nouvelle transaction crée un autre cache.
+ Le journal binaire est conservé jusqu’à ce qu’il soit sauvegardé et peut contenir 20 GiB (cache et journal) pendant une période prolongée.
Si vous utilisez `LOAD DATA LOCAL INFILE` pour charger les données, la récupération des données crée une quatrième copie au cas où la base de données devrait être récupérée à partir d’une sauvegarde exécutée avant le chargement. Pendant le récupération, MySQL extrait les données du journal binaire dans un fichier plat. MySQL exécute ensuite `LOAD DATA LOCAL INFILE`. Sur la base de l’exemple précédent, cette récupération nécessite un espace disque temporaire total de 40 GiB, soit 10 Gib chacun pour la table, le cache, le journal et le fichier local. Si l’espace disque disponible est inférieur à 40 GiB, la restauration échoue.
### Optimisation des charges de données importantes
Pour les chargements de données volumineux, désactivez la journalisation binaire afin de réduire la surcharge et les contraintes d’espace disque. Vous pouvez désactiver la journalisation binaire en définissant la période de rétention des sauvegardes sur 0. Une fois le chargement terminé, restaurez la période de rétention des sauvegardes sur la valeur appropriée différente de zéro. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md) et la [Période de rétention des sauvegardes](USER_ModifyInstance.Settings.md) dans la table des paramètres.
**Note**
Si l’instance de base de données est une instance de base de données source pour les réplicas en lecture, vous ne pouvez pas définir la période de rétention des sauvegardes sur 0.
Avant de charger les données, nous vous recommandons de créer un instantané de base de données. Pour plus d’informations, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## InnoDB
Les informations suivantes sur les options de journalisation des annulations et de récupération permettent de limiter la taille des transactions InnoDB afin d’optimiser les performances de la base de données.
### Compréhension de la journalisation des annulations par InnoDB
L’annulation est un mécanisme de journalisation qui permet l’annulation des transactions et prend en charge le contrôle de simultanéité multiversion (MVCC, Multi-Version Concurrency Control).
Pour les versions 5.7 et antérieures de MySQL, les journaux d’annulation sont stockés dans le tablespace système InnoDB (généralement ibdata1) et conservés jusqu’à ce que le thread de purge les supprime. Ainsi, les transactions de chargements de données volumineux peuvent entraîner un agrandissement conséquent du tablespace système et utiliser de l’espace disque que vous ne pouvez pas revendiquer sans recréer la base de données.
Pour toutes les versions de MySQL, le thread de purge doit attendre que la transaction active la plus ancienne soit validée ou annulée pour supprimer tous les journaux d’annulation. Si la base de données traite d’autres transactions pendant le chargement, leurs journaux d’annulation s’accumulent également et ne peuvent pas être supprimés, même si les transactions sont validées et qu’aucune transaction ne nécessite les journaux d’annulation pour MVCC. Dans ce cas, toutes les transactions, y compris celles en lecture seule, ralentissent. Ce ralentissement se produit parce que toutes les transactions accèdent à toutes les lignes modifiées par toutes les transactions, et pas seulement par les transactions de chargement. En effet, les transactions doivent parcourir les journaux d’annulation dont les transactions de chargement de longue durée ont empêché la purge lors du nettoyage du journal d’annulation. Cela affecte les performances de toute opération accédant aux lignes modifiées.
### Options de récupération de transactions InnoDB
Bien qu’InnoDB optimise les opérations de validation, les annulations de transactions importantes sont lentes. Pour accélérer la restauration, effectuez une point-in-time restauration ou restaurez un instantané de base de données. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md) et [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
## formats d’importation de données
MySQL prend en charge deux formats d’importation de données : fichiers plats et SQL. Passez en revue les informations relatives à chaque format afin de déterminer l’option la mieux adaptée à vos besoins.
### Fichiers plats
Pour les petites transactions, chargez des fichiers plats avec `LOAD DATA LOCAL INFILE`. Ce format d’importation de données offre les avantages suivants par rapport à l’utilisation de SQL :
+ Moins de trafic réseau
+ Réduction des coûts de transmission de données
+ Diminution des frais de traitement des bases de données
+ Accélération du traitement
`LOAD DATA LOCAL INFILE` charge la totalité du fichier plat comme une seule transaction. Maintenez une taille réduite pour chaque fichier afin de bénéficier des avantages suivants :
+ **Capacité de reprise** : vous pouvez suivre les fichiers qui ont été chargés. Si un problème survient pendant le chargement, vous pouvez reprendre la transaction là où elle s’est arrêtée. Vous devrez peut-être retransmettre des données à Amazon RDS, mais dans le cas de petits fichiers, la quantité retransmise est minimale.
+ **Chargement de données en parallèle** : si vous disposez d’une quantité suffisante d’IOPS et de bande passante du réseau pour le chargement d’un seul fichier, le chargement en parallèle peut faire gagner du temps.
+ **Contrôle du taux de chargement** : si le chargement de vos données a un impact négatif sur les autres processus, vous pouvez contrôler le taux de chargement en augmentant l’intervalle entre les fichiers.
Les transactions importantes réduisent les avantages liés à l’utilisation de `LOAD DATA LOCAL INFILE` pour importer des données. Lorsque vous ne pouvez pas diviser une grande quantité de données en fichiers plus petits, pensez à utiliser SQL.
### SQL
SQL possède un avantage principal sur les fichiers plats : vous pouvez facilement conserver une taille réduite pour les transactions. Cependant, le chargement avec SQL peut prendre beaucoup plus de temps que les fichiers plats. De plus, après un échec, il peut être difficile de définir à quel endroit reprendre : vous ne pouvez pas redémarrer les fichiers mysqldump. Si une défaillance se produit lors du chargement d’un fichier mysqldump, vous devez modifier ou remplacer le fichier avant que le chargement puisse reprendre. Sinon, après avoir corrigé la cause de la défaillance, vous pouvez restaurer à un instant dans le passé avant le chargement et renvoyer le fichier. Pour plus d’informations, consultez [Point-in-time rétablissement](USER_PIT.md).
## Utilisation d’instantanés de base de données Amazon RDS pour les points de contrôle de base de données
Si vous chargez des données sur de longues durées, par exemple des heures ou des jours, sans journalisation binaire, utilisez des instantanés de base de données pour fournir des points de contrôle périodiques en matière de sécurité des données. Chaque instantané de base de données crée une copie cohérente de votre instance de base de données, qui sert de point de récupération lors de défaillances du système ou d’événements de corruption de données. Les instantanés de base de données étant rapides, les points de contrôle fréquents ont un impact minimal sur les performances de chargement. Vous pouvez supprimer des instantanés de base de données précédents sans affecter la durabilité ou les capacités de récupération de la base de données. Pour plus d’informations sur les instantanés de base de données, consultez [Gestion des sauvegardes manuelles](USER_ManagingManualBackups.md).
## Réduction des temps de chargement des bases de données
Voici des conseils supplémentaires pour réduire les temps de chargement :
+ Créez tous les index secondaires avant le chargement des données dans les bases de données MySQL. Contrairement aux autres systèmes de base de données, MySQL reconstruit la table entière lors de l’ajout ou de la modification d’index secondaires. Ce processus crée une nouvelle table avec les modifications d’index, copie toutes les données et supprime la table d’origine.
+ Chargez les données dans l’ordre des clés primaires. Pour les tables InnoDB, cela peut réduire les temps de chargement de 75 % à 80 % et la taille des fichiers de données de 50 %.
+ Désactivez les contraintes liées aux clés étrangères en définissant `foreign_key_checks` sur `0`. Cela est souvent nécessaire pour les fichiers plats chargés avec `LOAD DATA LOCAL INFILE`. Pour tout chargement, la désactivation des contrôles par clé étrangère accélère le chargement des données. Une fois le chargement terminé, réactivez les contraintes en définissant `1` sur `foreign_key_checks` et vérifiez les données.
+ Chargez les données en parallèle à moins que vos ressources ne soient proches d’une limite. Pour permettre le chargement simultané sur plusieurs segments de table, utilisez des tables partitionnées le cas échéant.
+ Pour réduire la charge d’exécution du code SQL, combinez plusieurs instructions `INSERT` en opérations `INSERT` uniques à valeurs multiples. `mysqldump` implémente automatiquement cette optimisation.
+ Réduisez les opérations d’E/S du journal InnoDB en définissant `innodb_flush_log_at_trx_commit` sur `0`. Une fois le chargement terminé, restaurez `innodb_flush_log_at_trx_commit` vers `1`.
**Avertissement**
La définition de `innodb_flush_log_at_trx_commit` sur `0` oblige InnoDB à vider ses journaux toutes les secondes, et non à chaque validation. Ce paramètre améliore les performances, mais peut entraîner la perte de transactions en cas de défaillance du système.
+ Si vous chargez des données dans une instance de base de données ne disposant pas de réplicas en lecture, définissez `sync_binlog` sur `0`. Une fois le chargement terminé, restaurez `sync_binlog parameter` vers `1`.
+ Chargez les données dans une instance de base de données mono-AZ avant de convertir cette instance en déploiement multi-AZ. Si l’instance de base de données utilise déjà un déploiement multi-AZ, le passage à un déploiement mono-AZ pour le chargement des données n’est pas recommandé. Cela n’apporte que des améliorations marginales.
# Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL
Amazon RDS prend en charge l’importation de bases de données MySQL avec des fichiers de sauvegarde. Vous pouvez créer une sauvegarde de votre base de données, la stocker sur le fichier de sauvegarde sur Amazon S3, puis restaurer le fichier de sauvegarde sur une nouvelle instance de base de données Amazon RDS qui exécute MySQL. Amazon RDS prend en charge l’importation de fichiers de sauvegarde depuis Amazon S3 dans toutes les Régions AWS.
Le scénario décrit dans cette section restaure une sauvegarde d'une base de données sur site. Tant que la base de données est disponible, vous pouvez utiliser cette technique pour les bases de données situées dans d’autres emplacements, tels que Amazon EC2 ou d’autres services cloud.
Le schéma suivant illustre le scénario pris en charge.
![\[Importation MySQL de fichiers de sauvegarde depuis S3.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png)
Si votre base de données sur site peut être hors ligne lorsque vous créez, copiez et restaurez des fichiers de sauvegarde, nous vous recommandons d’utiliser les fichiers de sauvegarde pour importer votre base de données dans Amazon RDS. Si votre base de données ne peut pas être hors ligne, vous pouvez choisir l’une des méthodes suivantes :
+ **Journaux binaires** : importez d’abord des fichiers de sauvegarde depuis Amazon S3 vers Amazon RDS, comme expliqué dans cette rubrique. Utilisez ensuite la réplication de journal binaire (binlog) pour mettre à jour votre base de données. Pour de plus amples informations, veuillez consulter [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
+ **AWS Database Migration Service**— AWS Database Migration Service À utiliser pour migrer votre base de données vers Amazon RDS. Pour plus d'informations, voir [Qu'est-ce que c'est AWS Database Migration Service ?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)
## Présentation de la configuration de l’importation des fichiers de sauvegarde de Amazon S3 vers Amazon RDS
Pour importer des fichiers de sauvegarde d’Amazon S3 vers Amazon RDS, il vous faut les composants suivants :
+ Un compartiment Amazon S3 pour stocker vos fichiers de sauvegarde.
Si vous avez déjà un compartiment Amazon S3, vous pouvez l’utiliser. Si vous n’avez pas de compartiment Amazon S3, créez-en un nouveau. Pour plus d’informations, consultez [Créer un compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html).
+ Une sauvegarde de votre base de données sur site créée par XtraBackup Percona.
Pour de plus amples informations, veuillez consulter [Création de la sauvegarde de votre base de données](#MySQL.Procedural.Importing.Backup).
+ Rôle Gestion des identités et des accès AWS (IAM) permettant à Amazon RDS d'accéder au compartiment S3.
Si vous avez déjà un rôle IAM, vous pouvez l’utiliser et y associer des stratégies de confiance et d’autorisation. Pour de plus amples informations, veuillez consulter [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
Si vous n’avez pas de rôle IAM, vous avez deux options :
+ Vous pouvez créer manuellement un nouveau rôle IAM. Pour de plus amples informations, veuillez consulter [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
+ Vous pouvez laisser Amazon RDS créer un nouveau rôle IAM pour vous. Si vous souhaitez qu'Amazon RDS crée un nouveau rôle IAM pour vous, suivez la procédure qui utilise la section AWS Management Console in[Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL](#MySQL.Procedural.Importing.PerformingImport).
## Création de la sauvegarde de votre base de données
Utilisez le XtraBackup logiciel Percona pour créer votre sauvegarde. Nous vous recommandons d'utiliser la dernière version de Percona XtraBackup. Vous pouvez installer Percona XtraBackup à partir des [téléchargements de logiciels](https://www.percona.com/downloads/) sur le site Web de Percona.
**Avertissement**
Lors de la création d'une sauvegarde de base de données, XtraBackup vous pouvez enregistrer les informations d'identification dans le fichier xtrabackup\$1info. Assurez-vous que le paramètre `tool_command` du fichier xtrabackup\$1info ne contient aucune information sensible.
La XtraBackup version de Percona que vous utilisez dépend de la version de MySQL que vous sauvegardez.
+ **MySQL 8.4** — Utilisez la XtraBackup version 8.4 de Percona.
+ **MySQL 8.0** — Utilisez Percona XtraBackup version 8.0.
**Note**
Percona XtraBackup 8.0.12 et versions supérieures prennent en charge la migration de toutes les versions de MySQL 8.0. Si vous migrez vers RDS pour MySQL 8.0.32 ou supérieur, vous devez utiliser XtraBackup Percona 8.0.12 ou supérieur.
+ **MySQL 5.7** — Utilisez Percona XtraBackup version 2.4.
Vous pouvez utiliser Percona XtraBackup pour créer une sauvegarde complète de vos fichiers de base de données MySQL. Sinon, si vous utilisez déjà Percona XtraBackup pour sauvegarder les fichiers de votre base de données MySQL, vous pouvez télécharger vos répertoires et fichiers de sauvegarde complets et incrémentiels existants.
Pour plus d'informations sur la sauvegarde de votre base de données avec Percona XtraBackup, consultez [Percona XtraBackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html) sur le site Web de Percona.
### Création d'une sauvegarde complète avec Percona XtraBackup
Pour créer une sauvegarde complète de vos fichiers de base de données MySQL qu'Amazon RDS peut restaurer depuis Amazon S3, utilisez l' XtraBackup utilitaire Percona ()`xtrabackup`.
Par exemple, la commande suivante crée une sauvegarde d'une base de données MySQL et stocke les fichiers dans le dossier `/on-premises/s3-restore/backup`.
```
xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup
```
Si vous souhaitez compresser votre sauvegarde en un seul fichier, que vous pourrez diviser en plusieurs fichiers ultérieurement, si nécessaire, vous pouvez enregistrer votre sauvegarde dans l’un des formats suivants d’après votre version MySQL :
+ **Gzip (.gz)** : pour MySQL 5.7 et versions antérieures
+ **tar (.tar)** : pour MySQL 5.7 et versions antérieures
+ **Percona xbstream (.xbstream) :** pour toutes les versions de MySQL
**Note**
Percona XtraBackup 8.0 et versions ultérieures ne prend en charge que Percona xbstream pour la compression.
**MySQL 5.7 et versions antérieures**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers Gzip. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar.gz
```
**MySQL 5.7 et versions antérieures**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers tar. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=my_user --password=password --stream=tar \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.tar
```
**Toutes les versions de MySQL**
La commande suivante crée une sauvegarde de votre base de données MySQL, divisée en plusieurs fichiers xbstream. Remplacez les valeurs par vos propres informations.
```
xtrabackup --backup --user=myuser --password=password --stream=xbstream \
--target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \
- /on-premises/s3-restore/backup/backup.xbstream
```
**Note**
Si vous obtenez l’erreur suivante, cela indique peut-être que vous avez mélangé des formats de fichiers dans votre commande :
```
ERROR:/bin/tar: This does not look like a tar archive
```
### Utilisation de sauvegardes incrémentielles avec Percona XtraBackup
Si vous utilisez déjà Percona XtraBackup pour effectuer des sauvegardes complètes et incrémentielles de vos fichiers de base de données MySQL, vous n'avez pas besoin de créer une sauvegarde complète et de télécharger les fichiers de sauvegarde sur Amazon S3. Au lieu de cela, pour gagner du temps, copiez vos fichiers et répertoires de sauvegarde existants dans votre compartiment Amazon S3. Pour plus d'informations sur la création de sauvegardes incrémentielles à l'aide de Percona XtraBackup, voir [Création d'une sauvegarde incrémentielle](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html) sur le site Web de Percona.
Lorsque vous copiez les fichiers existants des sauvegardes complètes et incrémentielles dans un compartiment Amazon S3, vous devez copier de façon récursive le contenu du répertoire de base. Ce contenu inclut la sauvegarde complète, ainsi que tous les fichiers et répertoires des sauvegardes incrémentielles. Cette copie doit conserver la structure de répertoire du compartiment Amazon S3. Amazon RDS effectue une itération sur l'ensemble des fichiers et répertoires. Amazon RDS utilise le fichier `xtrabackup-checkpoints` inclus avec chaque sauvegarde incrémentielle pour identifier le répertoire de base et ordonner des sauvegardes incrémentielles selon leur plage de numéros de séquence de journal (LSN).
### Considérations relatives à la sauvegarde pour Percona XtraBackup
Amazon RDS utilise vos fichiers de sauvegarde sur la base des noms de fichier. Nommez vos fichiers de sauvegarde avec l’extension de fichier appropriée basée sur le format de fichier. Par exemple, utilisez `.xbstream` pour les fichiers stockés avec le format Percona xbstream.
Amazon RDS utilise vos fichiers de sauvegarde dans l'ordre alphabétique, ainsi que l'ordre numérique naturel. Utilisez l’option `split` lorsque vous émettez la commande `xtrabackup` pour vous assurer que vos fichiers de sauvegarde sont écrits et nommés dans l’ordre approprié.
Amazon RDS ne prend pas en charge les sauvegardes partielles créées à l'aide de XtraBackup Percona. Vous ne pouvez pas utiliser les options suivantes pour créer une sauvegarde partielle lorsque vous sauvegardez les fichiers source pour votre base de données :
+ `--tables`
+ `--tables-exclude`
+ `--tables-file`
+ `--databases`
+ `--databases-exclude`
+ `--databases-file`
## Création manuelle d’un rôle IAM
Si vous n'avez pas de rôle IAM, vous pouvez en créer manuellement un nouveau. Toutefois, si vous restaurez la base de données à l'aide du AWS Management Console, nous vous recommandons de demander à Amazon RDS de créer ce nouveau rôle IAM pour vous. Pour qu’Amazon RDS puisse créer ce rôle pour vous, suivez la procédure décrite dans la section [Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL](#MySQL.Procedural.Importing.PerformingImport).
Pour créer un rôle IAM manuellement afin d’importer votre base de données à partir de Amazon S3, créez un rôle pour déléguer des autorisations depuis le service Amazon RDS vers votre compartiment Amazon S3. Lorsque vous créez un rôle IAM, vous attachez des stratégies d'approbation et d'autorisation. Pour importer vos fichiers de sauvegarde à partir d’Amazon S3, utilisez des stratégies d’approbation et d’autorisation similaires aux exemples suivants. Pour plus d'informations sur la création du rôle, voir [Création d'un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html).
Les stratégies d'approbation et d'autorisation nécessitent que vous fournissiez un Amazon Resource Name (ARN). Pour plus d'informations sur le formatage de l'ARN, consultez [Amazon Resource Names (ARNs) et espaces AWS de noms de services](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
**Example stratégie d’approbation pour l’importation à partir d’Amazon S3**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleForBackup",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Example stratégie d’autorisation pour l’importation à partir de Amazon S3 — Autorisations des utilisateurs IAM**
Dans l'exemple suivant, remplacez *iam\$1user\$1id* par votre propre valeur.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3AccessRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/S3Access"
}
]
}
```
**Example stratégie d’autorisation pour l’importation à partir d’Amazon S3 — Autorisations des rôles**
Dans l'exemple suivant, remplacez *amzn-s3-demo-bucket* et *prefix* par vos propres valeurs.
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Action":
[
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action":
[
"s3:GetObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*"
},
{
"Effect": "Allow",
"Action":
[
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_id*"
]
}
]
}
```
Si vous incluez un préfixe de nom de fichier, vous devez inclure un astérisque (\$1) après le préfixe. Si vous ne voulez pas spécifier un préfixe, indiquez uniquement un astérisque.
## Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL
Vous pouvez importer des données depuis Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de l'API AWS Management Console AWS CLI, ou RDS.
### Console
**Pour importer des données à partir d'Amazon S3 vers une nouvelle instance de base de données MySQL**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le coin supérieur droit de la console Amazon RDS, choisissez l' Région AWS endroit où vous souhaitez créer votre instance de base de données. Choisissez le même Région AWS que le compartiment Amazon S3 qui contient la sauvegarde de votre base de données.
1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez **Restaurer à partir de S3**.
La page **Créer une base de données par restauration à partir de S3** s’affiche.
![\[Page Créer une base de données en restaurant à partir de S3 sur laquelle vous spécifiez les détails de la restauration d’une instance de base de données à partir de S3.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png)
1. Sous **Source S3** :
1. Choisissez le **compartiment S3** qui contient la sauvegarde.
1. (Facultatif) Pour **Préfixe S3**, saisissez un préfixe de chemin de fichier pour les fichiers stockés dans votre compartiment Amazon S3.
Si vous ne spécifiez pas de préfixe, Amazon RDS crée votre cluster/instance de base de données à l’aide de tous les fichiers et dossiers du dossier racine du compartiment S3. Si vous indiquez un préfixe, Amazon RDS crée votre instance de base de données à l’aide des fichiers et dossiers du compartiment S3 pour lesquels le chemin du fichier commence par le préfixe spécifié.
Par exemple, supposons que vous stockez vos fichiers de sauvegarde sur S3 dans un sous-dossier appelé « sauvegardes » et que vous avez plusieurs ensembles de fichiers de sauvegarde, chacun dans son propre répertoire (gzip\$1backup1, gzip\$1backup2, etc.). Dans ce cas, pour restaurer les fichiers dans le dossier gzip\$1backup1, spécifiez le préfixe sauvegardes/gzip\$1backup1.
1. Sous **Options du moteur** :
1. Dans le champ **Type de moteur**, choisissez **MySQL**.
1. Dans le champ **Version du moteur source**, choisissez la version MySQL majeure de votre base de données source.
1. Pour **Version du moteur**, choisissez la version mineure par défaut de votre version majeure MySQL dans votre Région AWS.
Dans le AWS Management Console, seule la version mineure par défaut est disponible. Une fois l’importation terminée, vous pouvez mettre à niveau votre instance de base de données.
1. Pour le **rôle IAM**, créez ou choisissez un rôle IAM avec la politique de confiance et la politique d’autorisation requises qui permettent à Amazon RDS d’accéder à votre compartiment Amazon S3. Effectuez l’une des opérations suivantes :
+ (Recommandé) Choisissez **Créer un nouveau rôle** et entrez le **nom du rôle IAM**. Avec cette option, Amazon RDS crée automatiquement le rôle avec la politique de confiance et la politique d’autorisation.
+ Choisissez un rôle IAM existant. Assurez-vous que ce rôle répond à tous les critères de [Création manuelle d’un rôle IAM](#MySQL.Procedural.Importing.Enabling.IAM).
1. Spécifiez les informations de votre instance de base de données. Pour plus d’informations sur chaque paramètre, consultez [Paramètres des instances de base de données](USER_CreateDBInstance.Settings.md).
**Note**
Veillez à allouer suffisamment de stockage à votre nouvelle instance de base de données afin que l’opération de restauration aboutisse.
Pour permettre automatiquement la croissance future, sous **Configuration de stockage supplémentaire**, sélectionnez **Activer la mise à l’échelle automatique du stockage**.
1. Choisissez des paramètres supplémentaires selon vos besoins.
1. Choisissez **Create database (Créer une base de données)**.
### AWS CLI
Pour importer des données depuis Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de AWS CLI, exécutez la commande [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) avec les options suivantes. Pour plus d’informations sur chaque paramètre, consultez [Paramètres des instances de base de données](USER_CreateDBInstance.Settings.md).
**Note**
Veillez à allouer suffisamment de stockage à votre nouvelle instance de base de données afin que l’opération de restauration aboutisse.
Pour activer la mise à l’échelle automatique du stockage et faciliter une croissance automatique ultérieure, utilisez l’option `--max-allocated-storage`.
+ `--allocated-storage`
+ `--db-instance-identifier`
+ `--db-instance-class`
+ `--engine`
+ `--master-username`
+ `--manage-master-user-password`
+ `--s3-bucket-name`
+ `--s3-ingestion-role-arn`
+ `--s3-prefix`
+ `--source-engine`
+ `--source-engine-version`
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds restore-db-instance-from-s3 \
2. --allocated-storage 250 \
3. --db-instance-identifier my_identifier \
4. --db-instance-class db.m5.large \
5. --engine mysql \
6. --master-username admin \
7. --manage-master-user-password \
8. --s3-bucket-name amzn-s3-demo-bucket \
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \
10. --s3-prefix bucket_prefix \
11. --source-engine my_sql \
12. --source-engine-version 8.0.32 \
13. --max-allocated-storage 1000
```
Pour Windows :
```
1. aws rds restore-db-instance-from-s3 ^
2. --allocated-storage 250 ^
3. --db-instance-identifier my_identifier ^
4. --db-instance-class db.m5.large ^
5. --engine mysql ^
6. --master-username admin ^
7. --manage-master-user-password ^
8. --s3-bucket-name amzn-s3-demo-bucket ^
9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^
10. --s3-prefix bucket_prefix ^
11. --source-engine mysql ^
12. --source-engine-version 8.0.32 ^
13. --max-allocated-storage 1000
```
### API RDS
Pour importer des données d'Amazon S3 vers une nouvelle instance de base de données MySQL à l'aide de l'API Amazon RDS, appelez l'opération [Restore DBInstance FromS3.](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
## Limitations et considérations relatives à l’importation de fichiers de sauvegarde d’Amazon S3 vers Amazon RDS
Les limitations et considérations suivantes s’appliquent à l’importation de fichiers de sauvegarde d’Amazon S3 vers une instance de base de données RDS for MySQL :
+ Vous pouvez uniquement migrer vos données vers une nouvelle instance de base de données, et non vers une instance de base de données existante.
+ Vous devez utiliser Percona XtraBackup pour sauvegarder vos données sur Amazon S3. Pour de plus amples informations, veuillez consulter [Création de la sauvegarde de votre base de données](#MySQL.Procedural.Importing.Backup).
+ Le compartiment Amazon S3 et l’instance de base de données RDS for MySQL doivent se trouver dans la même Région AWS.
+ Vous ne pouvez pas restaurer à partir des sources suivantes :
+ Une exportation d’instantané d’instance de base de données vers Amazon S3. Vous ne pouvez pas non plus migrer des données à partir de l’exportation d’un instantané d’instance de base de données dans votre compartiment Amazon S3.
+ Une base de données source chiffrée. Toutefois, vous pouvez chiffrer les données migrées. Vous pouvez également laisser les données non chiffrées pendant le processus de migration.
+ Une base de données MySQL 5.5 ou 5.6.
+ RDS for MySQL ne prend pas en charge Percona Server for MySQL en tant que base de données source, car il peut contenir des tables `compression_dictionary*` dans le `mysql schema`.
+ RDS for MySQL ne prend pas en charge la rétromigration pour les versions majeures ni mineures. Par exemple, il n’est pas possible de migrer de MySQL version 8.0 vers RDS for MySQL 5.7. De même, il n’est pas possible de migrer de MySQL version 8.0.32 vers MySQL version 8.0.26.
+ Amazon RDS ne prend pas en charge l’importation sur la classe d’instance de base de données db.t2.micro à partir d’Amazon S3. Toutefois, vous pouvez restaurer vers une autre classe d’instance de base de données, puis modifier la classe d’instance de base de données ultérieurement. Pour plus d'informations sur les classes d'instance , consultez [Spécifications matérielles pour les classes d'instances de base de données ](Concepts.DBInstanceClass.Summary.md).
+ Amazon S3 limite la taille d'un fichier chargé vers un compartiment Amazon S3 à 5 To. Si un fichier de sauvegarde dépasse 5 To, vous devez diviser celui-ci en plusieurs fichiers plus petits.
+ Amazon RDS limite le nombre de fichiers chargés vers un compartiment Amazon S3 à 1 million. Si les données de sauvegarde de votre base de données, y compris toutes les sauvegardes complètes et incrémentielles, dépassent 1 million de fichiers, utilisez un fichier Gzip (.gz), tar (.tar.gz) ou Percona xbstream (.xbstream) pour stocker les fichiers des sauvegardes complètes et incrémentielles dans le compartiment Amazon S3. Percona XtraBackup 8.0 prend uniquement en charge Percona xbstream pour la compression.
+ Pour fournir des services de gestion à chaque instance de base de données, Amazon RDS crée l’utilisateur `rdsadmin` lorsqu’il crée l’instance de base de données. Comme `rdsamin` est un utilisateur réservé dans Amazon RDS, les limitations suivantes s’appliquent :
+ Amazon RDS n’importe pas les fonctions, les procédures, les vues, les événements et les déclencheurs avec le définisseur `'rdsadmin'@'localhost'`. Pour plus d’informations, consultez [Objets stockés avec ’rdsadmin’@’localhost’ comme définisseur](#MySQL.Procedural.Importing.StoredObjects) et [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md).
+ Lors de la création de l’instance de base de données, Amazon RDS crée un utilisateur principal avec le maximum de privilèges pris en charge. Lors de la restauration à partir d’une sauvegarde, Amazon RDS supprime automatiquement tous les privilèges non pris en charge attribués aux utilisateurs importés.
Pour identifier les utilisateurs susceptibles d’être concernés, consultez [Comptes d’utilisateur avec des privilèges non pris en charge](#MySQL.Migrating.ExtMySQL.Prechecks.Users). Pour plus d’informations sur les privilèges pris en charge dans RDS for MySQL, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md).
+ Amazon RDS ne migre pas les tables créées par les utilisateurs dans le schéma `mysql`.
+ Vous devez configurer le paramètre `innodb_data_file_path` avec un seul fichier de données qui utilise le nom de fichier de données par défaut `ibdata1:12M:autoextend`. Vous pouvez migrer des bases de données comportant deux fichiers de données, ou avec un fichier de données portant un nom différent, à l’aide de cette méthode.
Les exemples suivants sont des noms de fichiers qu’Amazon RDS n’autorise pas :
+ `innodb_data_file_path=ibdata1:50M`
+ `ibdata2:50M:autoextend`
+ `innodb_data_file_path=ibdata01:50M:autoextend`
+ Vous ne pouvez pas migrer à partir d’une base de données source dotée de tables définies à l’extérieur du répertoire de données MySQL par défaut.
+ La taille maximale prise en charge pour les sauvegardes non compressées utilisant cette méthode est limitée à 64 Tio. Pour les sauvegardes compressées, cette limite est abaissée pour tenir compte de l’espace requis pour la décompression. Dans de tels cas, la taille de sauvegarde maximale prise en charge est `64 TiB - compressed backup size`.
Pour en savoir plus sur la taille maximale de base de données prise en charge par RDS for MySQL, consultez [Stockage SSD à usage général](CHAP_Storage.md#Concepts.Storage.GeneralSSD) et [Stockage SSD à IOPS provisionnées](CHAP_Storage.md#USER_PIOPS).
+ Aurora RDS ne prend pas en charge l’importation de MySQL ni d’autres composants et plugins externes.
+ Amazon RDS ne restaure pas tous les éléments de votre base de données. Nous vous recommandons d’enregistrer le schéma de base de données et les valeurs pour les éléments suivants à partir de votre base de données système MySQL source et de les ajouter à votre instance de base de données RDS for MySQL restauré après qu’il a été créé :
+ Comptes utilisateurs
+ Fonctions
+ Procédures stockées
+ Informations de fuseau horaire. Les informations de fuseau horaire sont chargées depuis le système d’exploitation local de votre instance de base de données RDS for MySQL. Pour de plus amples informations, veuillez consulter [Fuseau horaire local pour les instances de bases de données MySQL](MySQL.Concepts.LocalTimeZone.md).
### Objets stockés avec ’rdsadmin’@’localhost’ comme définisseur
Amazon RDS n’importe pas les fonctions, les procédures, les vues, les événements et les déclencheurs avec `'rdsadmin'@'localhost'` en tant que définisseur.
Vous pouvez utiliser le script SQL suivant sur votre base de données MySQL source pour répertorier les objets stockés qui possèdent le définisseur non pris en charge.
```
-- This SQL query lists routines with `rdsadmin`@`localhost` as the definer.
SELECT
ROUTINE_SCHEMA,
ROUTINE_NAME
FROM
information_schema.routines
WHERE
definer = 'rdsadmin@localhost';
-- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer.
SELECT
TRIGGER_SCHEMA,
TRIGGER_NAME,
DEFINER
FROM
information_schema.triggers
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists events with `rdsadmin`@`localhost` as the definer.
SELECT
EVENT_SCHEMA,
EVENT_NAME
FROM
information_schema.events
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists views with `rdsadmin`@`localhost` as the definer.
SELECT
TABLE_SCHEMA,
TABLE_NAME
FROM
information_schema.views
WHERE
DEFINER = 'rdsadmin@localhost';
```
### Comptes d’utilisateur avec des privilèges non pris en charge
Les comptes d’utilisateur dotés de privilèges non pris en charge par RDS for MySQL sont importés sans les privilèges non pris en charge. Pour obtenir la liste des privilèges pris en charge, consultez [Modèle de privilège basé sur les rôles pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md).
Vous pouvez exécuter la requête SQL suivante sur votre base de données source pour répertorier les comptes d’utilisateur dotés de privilèges non pris en charge.
```
SELECT
user,
host
FROM
mysql.user
WHERE
Shutdown_priv = 'y'
OR File_priv = 'y'
OR Super_priv = 'y'
OR Create_tablespace_priv = 'y';
```
# Importation de données à partir d’une base de données MySQL externe vers une instance de base de données Amazon RDS for MySQL
Vous pouvez importer des données à partir d’une base de données MySQL existante vers une instance de base de données RDS for MySQL. Pour ce faire, vous devez copier la base de données avec [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) et la transférer directement dans l’instance de base de données RDS for MySQL. L’utilitaire de ligne de commande `mysqldump` est généralement utilisé pour effectuer des sauvegardes et des transferts de données d’un serveur MySQL vers un autre. Il est inclus dans les logiciels clients MySQL.
**Note**
Si vous importez ou exportez de grandes quantités de données avec une instance de base de données MySQL, il est plus fiable et plus rapide de déplacer les données dans et en dehors d’Amazon RDS en utilisant des fichiers de sauvegarde `xtrabackup` et Amazon S3. Pour de plus amples informations, veuillez consulter [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Une commande `mysqldump` classique pour déplacer les données d’une base de données externe vers une instance de bases de données Amazon RDS ressemble à l’exemple suivant. Remplacez les valeurs par vos propres informations.
```
mysqldump -u local_user \
--databases database_name \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u RDS_user \
--port=port_number \
--host=host_name \
-pRDS_password
```
**Important**
Veillez à ne pas laisser d’espace entre l’option `-p` et le mot de passe saisi.
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans cet exemple.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
L’utilitaire `mysqldump` exclut ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
+ Pour effectuer l'importation, assurez-vous que l'utilisateur qui l'effectue a accès à l'instance de base de données. Pour de plus amples informations, veuillez consulter [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
Les paramètres utilisés sont les suivants :
+ `-u local_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la première utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données MySQL locale que vous identifiez avec le paramètre `--databases`.
+ `--databases database_name` : utilisez ce paramètre pour spécifier le nom de la base de données sur l’instance MySQL locale que vous souhaitez importer dans Amazon RDS.
+ `--single-transaction` : utilisez ce paramètre pour vérifier que toutes les données chargées depuis la base de données locale sont en cohérence avec un point dans le temps unique. S'il existe d'autres processus qui modifient les données pendant que `mysqldump` les lit, l'utilisation de ce paramètre permet de maintenir l'intégrité des données.
+ `--compress` : utilisez ce paramètre pour réduire la consommation de bande passante réseau par compression des données à partir de la base de données locale avant de les envoyer vers Amazon RDS.
+ `--order-by-primary` : utilisez ce paramètre pour réduire le temps de chargement en triant les données de chaque tableau sur par clé primaire.
+ `--routines` : utilisez ce paramètre si des routines telles que des procédures stockées ou des fonctions existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les routines pendant le processus d’importation. Ensuite, recréez manuellement les routines dans la base de données Amazon RDS.
+ `--triggers` : utilisez ce paramètre si des déclencheurs existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les déclencheurs pendant le processus d’importation. Ensuite, recréez manuellement les déclencheurs dans la base de données Amazon RDS.
+ `--events` : utilisez ce paramètre si des événements existent dans la base de données que vous copiez. Définissez le paramètre sur `0` pour exclure les événements pendant le processus d’importation. Ensuite, recréez manuellement les événements dans la base de données Amazon RDS.
+ `-plocal_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la première utilisation de ce paramètre, spécifiez le mot de passe du compte utilisateur identifié avec le premier paramètre `-u`.
+ `-u RDS_user` : utilisez ce paramètre pour spécifier un nom d’utilisateur. Lors de la seconde utilisation de ce paramètre, spécifiez le nom d’un compte utilisateur sur la base de données par défaut pour l’instance de bases de données MySQL que vous identifiez avec le paramètre `--host`.
+ `--port port_number` : utilisez ce paramètre pour spécifier le port pour votre instance de base de données MySQL. Par défaut, il s’agit du port 3306, sauf si vous avez modifié la valeur lorsque vous avez créé l’instance de base de données.
+ `--host host_name` : utilisez ce paramètre pour spécifier le nom du système de nom de domaine (DNS) du point de terminaison de l’instance de base de données Amazon RDS, par exemple, `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
+ `-pRDS_password` : utilisez ce paramètre pour spécifier un mot de passe. Lors de la seconde utilisation de ce paramètre, vous spécifiez le mot de passe du compte utilisateur identifié par le second paramètre `-u`.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump`. Pour ce faire, incluez les paramètres suivants avec votre commande `mysqldump` :
+ `--routines=0`
+ `--triggers=0`
+ `--events=0`
**Exemple**
L’exemple suivant copie l’exemple de base de données `world` de l’hôte local sur une instance de bases de données RDS for MySQL. Remplacez les valeurs par vos propres informations.
Pour Linux, macOS ou Unix :
```
sudo mysqldump -u local_user \
--databases world \
--single-transaction \
--compress \
--order-by-primary \
--routines=0 \
--triggers=0 \
--events=0 \
-plocal_password | mysql -u rds_user \
--port=3306 \
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com \
-pRDS_password
```
Pour Windows :
Exécutez la commande suivante dans une invite de commandes ouverte en cliquant avec le bouton droit sur **Invite de commandes** dans le menu Programmes de Windows, puis en choisissant **Exécuter en tant qu’administrateur**. Remplacez les valeurs par vos propres informations.
```
mysqldump -u local_user ^
--databases world ^
--single-transaction ^
--compress ^
--order-by-primary ^
--routines=0 ^
--triggers=0 ^
--events=0 ^
-plocal_password | mysql -u RDS_user ^
--port=3306 ^
--host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^
-pRDS_password
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
# Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite
Dans certains cas, vous pouvez avoir besoin d’importer des données d’une base de données MySQL externe qui prend en charge une application active vers une instance de base de données RDS for MySQL, ou un cluster de bases de données multi-AZ RDS for MySQL. Utilisez la procédure suivante pour réduire l’impact sur la disponibilité des applications. Cette procédure peut s’avérer également utile si vous travaillez avec une base de données très volumineuse. Cette procédure vous permet de réduire le coût de l'importation en diminuant la quantité de données transmises à AWS via le réseau.
Dans cette procédure, vous transférez une copie des données de votre base de données vers une instance Amazon EC2 et vous importez les données dans une nouvelle base de données Amazon RDS. Vous utilisez ensuite la réplication pour intégrer la base de données Amazon RDS up-to-date à votre instance externe active, avant de rediriger votre application vers la base de données Amazon RDS. Configurez la réplication en fonction des coordonnées des journaux binaires.
**Note**
Si vous souhaitez importer des données dans une instance de base de données RDS for MySQL et que votre scénario le permet, nous recommandons de déplacer les données dans et hors d’Amazon RDS en utilisant des fichiers de sauvegarde et Amazon S3. Pour de plus amples informations, veuillez consulter [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Le schéma suivant montre l’importation d’une base de données MySQL externe dans une base de données MySQL sur Amazon RDS.
![\[Flux de travail qui montre l’importation d’une base de données MySQL externe dans une base de données MySQL sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_1.png)
## Tâche 1 : Créer une copie de votre base de données existante
La première étape du processus de migration d’une grande quantité de données vers une base de données RDS for MySQL avec une durée d’indisponibilité minimale consiste à créer une copie des données sources.
Le schéma suivant montre la création d’une sauvegarde de base de données MySQL.
![\[Flux de travail qui montre la création d’une sauvegarde de la base de données MySQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png)
Vous pouvez recourir à l'utilitaire `mysqldump` pour créer une sauvegarde de base de données au format SQL ou texte délimité. Nous vous recommandons d’effectuer un test avec chaque format dans un environnement autre que celui de production afin de déterminer la méthode qui minimise le temps d’exécution de `mysqldump`.
Nous vous recommandons également de comparer les performances de `mysqldump` avec les avantages offerts par l’utilisation du format texte délimité pour le chargement. Une sauvegarde à l’aide du format texte délimité crée un fichier texte séparé par des tabulations pour chaque table vidée. Pour réduire le temps nécessaire à l’importation de votre base de données, vous pouvez charger ces fichiers en parallèle en utilisant la commande `LOAD DATA LOCAL INFILE`. Pour plus d’informations, consultez [Étape 5 : Charger les données](mysql-importing-data-any-source.md#mysql-importing-data-any-source-load-data) dans la procédure Importation de données à partir de n’importe quelle source.
Avant de commencer l’opération de sauvegarde, assurez-vous de définir les options de réplication sur la base de données MySQL que vous copiez vers Amazon RDS. Les options de réplication incluent l’activation de la journalisation binaire et la configuration d’un ID de serveur unique. La définition de ces options oblige votre serveur à démarrer la journalisation des transactions de base de données et le prépare à être une instance de réplication source ultérieurement dans le processus.
Assurez-vous que vous êtes conscient des recommandations et des considérations suivantes :
+ Utilisez l'option `--single-transaction` avec `mysqldump`, car elle vide un état cohérent de la base de données. Pour vous assurer de la validité d'un fichier de vidage, n'exécutez pas les instructions DDL (Data Definition Language) pendant l'exécution de `mysqldump`. Vous pouvez planifier une fenêtre de maintenance pour ces opérations.
+ Excluez les schémas suivants du fichier de vidage :
+ `sys`
+ `performance_schema`
+ `information_schema`
L’utilitaire `mysqldump` exclut ces schémas par défaut.
+ Si vous devez migrer des utilisateurs et des privilèges, pensez à utiliser un outil qui génère le langage de contrôle des données (DCL) pour les recréer, tel que l'[pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html)utilitaire.
### Pour définir les options de réplication
1. Modifiez le fichier `my.cnf`. Ce fichier se trouve généralement sous `/etc`.
```
sudo vi /etc/my.cnf
```
Ajoutez les options `log_bin` et `server_id` à la section `[mysqld]`. L’option `log_bin` fournit un identifiant de nom de fichier pour les fichiers journaux binaires. L’option `server_id` fournit un identifiant unique pour le serveur dans les relations source/réplica.
L’exemple suivant illustre la section `[mysqld]` mise à jour d’un fichier `my.cnf` :
```
[mysqld]
log-bin=mysql-bin
server-id=1
```
Pour plus d’informations, consultez [Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL.
1. Pour la réplication avec un cluster de bases de données multi-AZ, définissez les paramètres `ENFORCE_GTID_CONSISTENCY` et `GTID_MODE` sur `ON`.
```
mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
```
```
mysql> SET @@GLOBAL.GTID_MODE = ON;
```
Ces paramètres ne sont pas requis pour la réplication avec une instance de base de données.
1. Redémarrez le service `mysql`.
```
sudo service mysqld restart
```
### Pour créer une copie de sauvegarde de votre base de données existante
1. Créez une sauvegarde de vos données à l'aide de l'utilitaire `mysqldump`, en spécifiant un format SQL ou un format texte délimité.
Pour MySQL 8.0.25 et versions antérieures, spécifiez `--master-data=2` pour créer un fichier de sauvegarde qui peut être utilisé pour démarrer la réplication entre les serveurs. Pour MySQL 8.0.26 et versions ultérieures, spécifiez `--source-data=2` pour créer un fichier de sauvegarde qui peut être utilisé pour démarrer la réplication entre les serveurs. Pour plus d’informations, consultez [mysqldump – Programme de sauvegarde de base de données](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) dans la documentation MySQL.
Pour améliorer les performances et assurer l’intégrité des données, utilisez les options `--order-by-primary` et `--single-transaction` pour `mysqldump`.
Pour éviter d’inclure la base de données système MySQL dans la sauvegarde, n’utilisez pas l’option `--all-databases` avec `mysqldump`. Pour plus d’informations, consultez [Création d’un instantané de données avec mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) dans la documentation MySQL.
Utilisez `chmod`, si nécessaire, pour vous assurer que le répertoire où le fichier de sauvegarde est en cours de création est accessible en écriture.
**Important**
Sur Windows, exécutez la fenêtre de commande en tant qu’administrateur.
+ Pour produire une sortie SQL, utilisez la commande suivante :
Pour Linux, macOS ou Unix :
```
sudo mysqldump \
--databases database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u local_user \
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Pour Windows :
```
mysqldump ^
--databases database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-r backup.sql ^
-u local_user ^
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
+ Pour produire une sortie à texte délimité, utilisez la commande suivante :
Pour Linux, macOS ou Unix :
```
sudo mysqldump \
--tab=target_directory \
--fields-terminated-by ',' \
--fields-enclosed-by '"' \
--lines-terminated-by 0x0d0a \
database_name \
--master-data=2 \
--single-transaction \
--order-by-primary \
-ppassword
```
Pour Windows :
```
mysqldump ^
--tab=target_directory ^
--fields-terminated-by "," ^
--fields-enclosed-by """ ^
--lines-terminated-by 0x0d0a ^
database_name ^
--master-data=2 ^
--single-transaction ^
--order-by-primary ^
-ppassword
```
**Note**
Une bonne pratique de sécurité consiste à spécifier des informations d’identification autres que les invites affichées dans l’exemple.
Assurez-vous de créer manuellement les procédures stockées, déclencheurs, fonctions ou événements dans votre base de données Amazon RDS. Si vous avez l’un de ces objets dans la base de données que vous copiez, excluez-les lorsque lors de l’exécution de `mysqldump`. Pour ce faire, incluez les arguments suivants dans votre commande `mysqldump` :
`--routines=0`
`--triggers=0`
`--events=0`
Pour MySQL 8.0.22 et versions antérieures, lorsque vous exécutez `mysqldump` et spécifiez le format texte délimité, un commentaire `CHANGE MASTER TO` est retourné. Ce commentaire contient le nom du fichier journal maître et son emplacement. Pour MySQL 8.0.23 et versions ultérieures, lorsque vous exécutez `mysqldump` et spécifiez le format texte délimité, un commentaire `CHANGE REPLICATION SOURCE TO` est retourné. Ce commentaire contient le nom du fichier journal source et son emplacement. Si l’instance externe est MySQL 8.0.23 et versions ultérieures, notez les valeurs pour `MASTER_LOG_FILE` et `MASTER_LOG_POS`. Vous avez besoin de ces valeurs lors de la configuration de la réplication.
La sortie suivante est retournée pour MySQL 8.0.22 et versions antérieures :
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
```
La sortie suivante est retournée pour MySQL 8.0.23 et versions ultérieures :
```
-- Position to start replication or point-in-time recovery from
--
-- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107;
```
Pour MySQL 8.0.22 et versions antérieures, si vous utilisez le format SQL, vous pouvez obtenir le nom du fichier journal principal et son emplacement dans le commentaire `CHANGE MASTER TO` du fichier de sauvegarde. Pour MySQL 8.0.23 et versions ultérieures, si vous utilisez le format SQL, vous pouvez obtenir le nom du fichier journal source et son emplacement dans le commentaire `CHANGE REPLICATION SOURCE TO` du fichier de sauvegarde.
1. Compressez les données copiées afin de réduire la quantité de ressources réseau nécessaires pour copier vos données sur la base de données Amazon RDS. Notez la taille du fichier de sauvegarde. Vous avez besoin de cette information lorsque vous déterminez la taille de l'instance Amazon EC2 à créer. Lorsque vous avez terminé, compressez le fichier de sauvegarde à l’aide de GZIP ou de votre utilitaire de compression favori.
+ Pour compresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql
```
+ Pour compresser une sortie à texte délimité, utilisez la commande suivante :
```
tar -zcvf backup.tar.gz target_directory
```
## Tâche 2 : Créer une instance Amazon EC2 et copier la base de données compressée
La copie du fichier de sauvegarde compressé de votre base de données sur une instance Amazon EC2 nécessite moins de ressources réseau que l’exécution d’une copie directe de données non compressées entre instances de bases de données. Une fois que vos données sont dans Amazon EC2, vous pouvez les copier directement de cet emplacement vers votre base de données MySQL. Pour que vous puissiez économiser sur le coût des ressources réseau, votre instance Amazon EC2 doit être Région AWS identique à votre instance de base de données Amazon RDS. Le fait d’avoir l’instance Amazon EC2 dans la même Région AWS que votre base de données Amazon RDS a également pour effet de réduire la latence réseau pendant l’importation.
Le schéma suivant montre la copie de la sauvegarde de base de données vers une instance Amazon EC2.
![\[Flux de travail montrant la copie de la sauvegarde de base de données vers une instance Amazon EC2.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_3.png)
### Pour créer une instance Amazon EC2 et copier vos données
1. Dans l' Région AWS endroit où vous prévoyez de créer la base de données Amazon RDS, créez un cloud privé virtuel (VPC), un groupe de sécurité VPC et un sous-réseau VPC. Assurez-vous que les règles entrantes de votre groupe de sécurité VPC autorisent les adresses IP requises pour que votre application se connecte à AWS. Vous pouvez spécifier une plage d’adresses IP (par exemple, `203.0.113.0/24`) ou un autre groupe de sécurité VPC. Vous pouvez utiliser la [console Amazon VPC](https://console.aws.amazon.com/vpc) pour créer et gérer des sous-réseaux et VPCs des groupes de sécurité. Pour plus d’informations, consultez [Démarrez avec Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Ouvrez la [console Amazon EC2](https://console.aws.amazon.com/ec2) et choisissez celle qui doit contenir Région AWS à la fois votre instance Amazon EC2 et votre base de données Amazon RDS. Lancez une instance Amazon EC2 à l’aide du VPC, du sous-réseau et du groupe de sécurité que vous avez créés à l’étape 1. Vérifiez que vous sélectionnez un type d’instance avec un stockage suffisant pour le fichier de sauvegarde de votre base de données une fois qu’il est décompressé. Pour plus d’informations sur les instances Amazon EC2, consultez [Démarrez avec Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Pour vous connecter à votre base de données Amazon RDS à partir de votre instance Amazon EC2, modifiez votre groupe de sécurité VPC. Ajoutez une règle de trafic entrant en spécifiant l’adresse IP privée de votre instance EC2. L’adresse IP privée se trouve sous l’onglet **Détails** du volet **Instance** de la fenêtre de la console EC2. Pour modifier le groupe de sécurité VPC et ajouter une règle de trafic entrant, choisissez **Security Groups** (Groupes de sécurité) dans le panneau de navigation de la console EC2, choisissez votre groupe de sécurité et ajoutez une règle de trafic entrant pour MySQL/Aurora en spécifiant l’adresse IP privée de votre instance EC2. Pour apprendre à ajouter une règle de trafic entrant à un groupe de sécurité VPC, consultez [Règles du groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l’utilisateur Amazon VPC Private Cloud*.
1. Copiez le fichier de sauvegarde compressé de votre base de données depuis votre système local vers votre instance Amazon EC2. Utilisez `chmod`, si nécessaire, pour vous assurer d’avoir l’autorisation d’écriture dans le répertoire cible de l’instance Amazon EC2. Vous pouvez utiliser `scp` ou un client SSH pour copier le fichier. Voici un exemple de commande `scp` :
```
scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz
```
**Important**
Lorsque vous copiez des données sensibles, assurez-vous d’utiliser un protocole de transfert réseau sécurisé.
1. Connectez-vous à votre instance Amazon EC2, puis installez les dernières mises à jour et les outils clients MySQL à l'aide des commandes suivantes :
```
sudo yum update -y
sudo yum install mysql -y
```
Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
**Important**
Cet exemple installe le client MySQL sur une Amazon Machine Image (AMI) pour une distribution Amazon Linux. Cet exemple n’installe pas le client MySQL sur une autre distribution, comme Ubuntu ou Red Hat Enterprise Linux. Pour en savoir plus sur l’installation de MySQL, consultez [Installation de MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html) dans la documentation MySQL.
1. Une fois connecté à votre instance Amazon EC2, décompressez le fichier de sauvegarde de votre base de données. Les commandes suivantes sont des exemples.
+ Pour décompresser une sortie SQL, utilisez la commande suivante :
```
gzip backup.sql.gz -d
```
+ Pour décompresser une sortie texte délimité, utilisez la commande suivante :
```
tar xzvf backup.tar.gz
```
## Tâche 3 : Créer une base de données MySQL et importer les données depuis votre instance Amazon EC2
En créant une instance de base de données RDS for MySQL, ou un cluster de bases de données multi-AZ RDS for MySQL dans la même Région AWS que votre instance Amazon EC2, vous pouvez importer le fichier de sauvegarde de base de données plus rapidement à partir d’Amazon EC2 que via Internet.
Le schéma suivant montre l’importation de la sauvegarde d’une instance Amazon EC2 vers une base de données MySQL.
![\[Flux de travail montrant l’importation de la sauvegarde de l’instance EC2 vers la base de données MySQL.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png)
### Pour créer une base de données MySQL et importer vos données
1. Déterminez quelle classe d’instance de base de données et quelle quantité d’espace de stockage sont nécessaires pour prendre en charge la charge de travail attendue pour cette base de données Amazon RDS. Dans le cadre de ce processus, décidez de l’espace suffisant et de la capacité de traitement qui conviennent à vos procédures de chargement des données. Décidez également ce qui est nécessaire pour gérer la charge de travail de production. Vous pouvez estimer ces éléments en fonction de la taille et des ressources de la base de données source MySQL. Pour de plus amples informations, veuillez consulter [Classes d'instances de base de données ](Concepts.DBInstanceClass.md).
1. Créez une instance de base de données ou un cluster de base de données multi-AZ dans celui Région AWS qui contient votre instance Amazon EC2.
Pour créer un cluster de bases de données multi-AZ RDS for MySQL, suivez les instructions dans [Création d’un cluster de bases de données Multi-AZ pour Amazon RDS](create-multi-az-db-cluster.md).
Pour créer une instance de base de données RDS for MySQL, suivez les instructions dans [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md) et utilisez les instructions suivantes :
+ Spécifiez une version du moteur de base de données compatible avec votre instance de base de données source.
+ Spécifiez les mêmes cloud privé virtuel (VPC) et groupe de sécurité VPC que pour votre instance Amazon EC2. Cette approche garantit que votre instance Amazon EC2 et votre instance Amazon RDS sont visibles l’une de l’autre sur le réseau. Assurez-vous que votre instance de base de données est accessible au public. Pour configurer la réplication avec votre base de données source comme décrit dans l’une des sections suivantes, votre instance de base de données doit être publiquement accessible.
+ Ne configurez pas plusieurs zones de disponibilité, la rétention des sauvegardes ou les réplicas en lecture tant que vous n’avez pas importé la sauvegarde de la base de données. Lorsque l'importation est terminée, vous pouvez configurer l'option multi-AZ et la rétention des sauvegardes pour l'instance de production.
1. Vérifiez les options de configuration par défaut de la base de données Amazon RDS. Si le groupe de paramètres par défaut pour la base de données ne dispose pas des options de configuration que vous voulez, trouvez un autre groupe qui les possède ou créez un groupe de paramètres. Pour plus d’informations sur la création d’un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Connectez-vous à la nouvelle base de données Amazon RDS en tant qu’utilisateur principal. Créez ensuite les utilisateurs requis pour prendre en charge les administrateurs, les applications et les services qui doivent accéder à l’instance de base de données. Le nom d’hôte de la base de données Amazon RDS est la valeur **Point de terminaison** de cette instance de base de données sans le numéro de port. Par exemple, `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de la base de données dans la console Amazon RDS.
1. Connectez-vous à votre instance EC2 Amazon. Pour plus d’informations, consultez [Connexion à votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) pour les instances Linux dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
1. Connectez-vous à votre base de données Amazon RDS comme hôte distant depuis votre instance Amazon EC2 à l’aide de la commande `mysql`. Voici un exemple de commande :
```
mysql -h host_name -P 3306 -u db_master_user -p
```
*host\$1name*Il s'agit du point de terminaison de la base de données Amazon RDS.
1. À l’invite `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données. Cette commande charge les données dans l’instance de base de données Amazon RDS.
+ Pour le format SQL, utilisez la commande suivante :
```
mysql> source backup.sql;
```
+ Pour le format texte délimité, créez d’abord la base de données, s’il ne s’agit pas de la base de données par défaut que vous avez créée lors de la configuration de la base de données Amazon RDS.
```
mysql> create database database_name;
mysql> use database_name;
```
Créez ensuite les tables.
```
mysql> source table1.sql
mysql> source table2.sql
etc...
```
Enfin, importez les données.
```
mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
mysql> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a';
etc...
```
Pour améliorer les performances, vous pouvez exécuter ces opérations en parallèle à partir de plusieurs connexions de telle sorte que l’ensemble de vos tables soit créé et chargé simultanément.
**Note**
Si vous avez utilisé des options de mise en forme des données avec `mysqldump` lorsque vous avez initialement vidé la table, assurez-vous d’utiliser les mêmes options avec `LOAD DATA LOCAL INFILE` pour garantir une interprétation correcte du contenu du fichier de données.
1. Exécutez une simple requête `SELECT` sur l’une ou les deux tables de la base de données importée afin de vérifier que l’importation s’est déroulée avec succès.
Si vous n'avez plus besoin de l'instance Amazon EC2 utilisée dans cette procédure, mettez-la hors service afin de réduire votre AWS consommation de ressources. Pour mettre fin à une instance EC2, consultez [Terminer une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
## Tâche 4 : Répliquer les données de votre base de données externe vers votre nouvelle base de données Amazon RDS
Votre base de données source a probablement été mise à jour pendant la copie et le transfert des données vers la base de données MySQL. Ainsi, vous pouvez utiliser la réplication pour intégrer la base de données up-to-date copiée à la base de données source.
![\[Flux de travail qui montre la réplication des données de la base de données externe MySQL vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_5.png)
Les autorisations requises pour démarrer la réplication sur une base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Vous devez donc utiliser la procédure stockée Amazon RDS appropriée pour votre version de moteur majeure :
+ [mysql\$1rds\$1set\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) pour configurer la réplication et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour la démarrer
### Pour démarrer la réplication
Dans la Tâche 1, [lorsque vous avez défini les options de réplication](#mysql-importing-data-reduced-downtime-set-replication-options), vous avez activé la journalisation binaire et défini un ID de serveur unique pour votre base de données source. À présent, vous pouvez configurer votre base de données Amazon RDS comme réplica avec votre base de données active comme instance de réplication source.
1. Dans la console Amazon RDS, ajoutez l’adresse IP du serveur qui héberge la base de données source au groupe de sécurité VPC de la base de données Amazon RDS. Pour plus d’informations sur la configuration d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
Il se peut aussi que vous ayez besoin de configurer votre réseau local pour autoriser les connexions à partir de l’adresse IP de votre base de données Amazon RDS, de telle sorte qu’elle puisse communiquer avec votre instance source. Pour obtenir l’adresse IP de la base de données Amazon RDS, utilisez la commande `host` :
```
host host_name
```
*host\$1name*Il s'agit du nom DNS du point de terminaison de la base de données Amazon RDS, par exemple`myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de l’instance de base de données dans la console Amazon RDS.
1. A l’aide du client de votre choix, connectez-vous à l’instance source et créez un utilisateur à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. Voici un exemple de commande :
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour l’instance source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l’utilisateur « `repl_user` » de votre domaine, émettez la commande suivante :
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Transformez la base de données Amazon RDS en réplica. Connectez-vous à la base de données Amazon RDS en tant qu’utilisateur principal et identifiez la base de données source comme instance de réplication source à l’aide de la procédure stockée Amazon RDS appropriée.
+ [mysql\$1rds\$1set\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)
Si vous avez un fichier de sauvegarde au format SQL, utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 4. Si vous avez utilisé le format texte délimité, utilisez le nom et la position que vous avez déterminés lors de la création des fichiers de sauvegarde. Les commandes suivantes sont des exemples :
**MySQL versions 8.4 et ultérieures**
```
CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MySQL 8.0 et versions antérieures**
```
CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Spécifiez des informations d’identification autres que celles affichées ici, en tant que bonne pratique de sécurité.
1. Pour démarrer la réplication sur la base de données Amazon RDS, exécutez la commande suivante qui utilise la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) :
```
CALL mysql.rds_start_replication;
```
1. Sur la base de données Amazon RDS, exécutez la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) pour déterminer quand le réplica est à jour avec l’instance de réplication source. Les résultats de la commande `SHOW REPLICA STATUS` incluent le champ `Seconds_Behind_Master`. Lorsque le champ `Seconds_Behind_Master` renvoie 0, le réplica est à jour avec l’instance de réplication source.
**Note**
Les versions précédentes de MySQL utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `SHOW SLAVE STATUS`.
1. Une fois que la base de données Amazon RDS est à jour, activez les sauvegardes automatiques de façon à pouvoir restaurer la base de données si nécessaire. Vous pouvez activer ou modifier les sauvegardes automatiques de votre base de données Amazon RDS à l’aide de la [console Amazon RDS](https://console.aws.amazon.com/rds/). Pour de plus amples informations, veuillez consulter [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
## Tâche 5 : Rediriger votre application active vers votre instance Amazon RDS
Une fois que la base de données MySQL est à jour avec l’instance de réplication source, vous pouvez mettre à jour votre application active et utiliser l’instance Amazon RDS.
![\[Flux de travail qui montre l’arrêt de la réplication et la direction de l’application active vers la base de données sur Amazon RDS.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_6.png)
### Pour rediriger votre application active vers votre base de données MySQL et arrêter la réplication
1. Pour ajouter le groupe de sécurité VPC pour la base de données Amazon RDS, ajoutez l’adresse IP du serveur qui héberge l’application. Pour plus d’informations sur la modification d’un groupe de sécurité VPC, consultez [Configuration de règles de groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
1. Vérifiez que le champ `Seconds_Behind_Master` de la commande [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) a pour résultat 0, valeur indiquant que le réplica est à jour avec l’instance de réplication source.
```
SHOW REPLICA STATUS;
```
**Note**
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 alors `SHOW SLAVE STATUS`.
1. Fermez toutes les connexions à la source une fois leurs transactions terminées.
1. Mettez à jour votre application pour utiliser la base de données Amazon RDS. Cette mise à jour implique généralement de modifier les paramètres de connexion pour identifier le nom d'hôte et le port de la base de données Amazon RDS, le compte utilisateur et le mot de passe avec lesquels se connecter, et la base de données à utiliser.
1. Connectez-vous à l’instance de base de données.
Pour un cluster de bases de données multi-AZ, connectez-vous à l'instance de base de données d'écriture.
1. Arrêtez la réplication pour l’instance Amazon RDS en exécutant la commande suivante qui utilise la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) :
```
CALL mysql.rds_stop_replication;
```
1. Réinitialisez la configuration de réplication de telle sorte que cette instance ne soit plus identifiée comme un réplica en utilisant la procédure stockée Amazon RDS appropriée sur votre base de données Amazon RDS :
+ [mysql\$1rds\$1reset\$1external\$1master (versions majeures RDS for MySQL 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source)
**MySQL versions 8.4 et ultérieures**
```
CALL mysql.rds_reset_external_source;
```
**MySQL 8.0 et versions antérieures**
```
CALL mysql.rds_reset_external_master;
```
1. Activez des fonctions Amazon RDS supplémentaires, telles que la prise en charge Multi-AZ et les réplicas en lecture. Pour plus d’informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md) et [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
# Importation de données depuis n’importe quelle source vers une instance de base de données Amazon RDS for MySQL
Amazon RDS vous permet de migrer les données MySQL existantes depuis n’importe quelle source vers une instance de base de données RDS for MySQL. Vous pouvez transférer des données depuis des bases de données sur site, d’autres fournisseurs de cloud ou des instances de base de données RDS for MySQL existantes vers votre instance de base de données RDS for MySQL cible. Cette fonctionnalité vous permet de consolider les bases de données, de mettre en œuvre des solutions de reprise après sinistre ou d’y basculer à partir de bases de données autogérées. Les scénarios courants incluent le passage de serveurs MySQL auto-hébergés vers des instances de base de données Amazon RDS entièrement gérées, la consolidation de plusieurs bases de données MySQL en une seule instance de base de données ou la création d’environnements de test avec des données de production. Les sections suivantes fournissent des step-by-step instructions pour importer vos données MySQL à l'aide de méthodes telles que `mysqldump` les fichiers de sauvegarde ou la réplication.
## Étape 1 : Créer les fichiers plats contenant les données à charger
Utilisez un format courant, tel que CSV (valeurs séparées par des virgules), pour stocker les données à charger. Chaque table doit avoir son propre fichier ; les données de plusieurs tables ne peuvent pas être combinées dans le même fichier. Attribuez à chaque fichier le même nom que celui de la table à laquelle il correspond. L’extension du fichier est laissée à votre libre choix. Par exemple, si le nom de la table est `sales`, le nom du fichier peut être `sales.csv` ou `sales.txt`.
Si possible, triez les données sur la clé primaire de la table en cours de chargement. Cela améliore de façon spectaculaire les temps de chargement et réduit le stockage disque requis.
Cette procédure est d'autant plus rapide et efficace que les fichiers ont une petite taille. Si la taille non compressée d’un fichier est supérieure à 1 Gio, scindez-le en plusieurs fichiers et chargez chacun d’eux séparément.
Sur les systèmes Unix (Linux inclus), utilisez la commande `split`. Par exemple, la commande suivante fractionne le fichier `sales.csv` en plusieurs fichiers de moins d’1 Gio, le fractionnement n’intervenant qu’aux sauts de ligne (-C 1 024m). Les noms des nouveaux fichiers incluent des suffixes numériques croissants. La commande suivante génère des fichiers portant des noms tels que `sales.part_00` et `sales.part_01`.
```
split -C 1024m -d sales.csv sales.part_
```
Des utilitaires semblables sont disponibles sur les autres systèmes d’exploitation.
Vous pouvez stocker les fichiers plats n’importe où. Toutefois, lorsque vous chargez les données à l’[Étape 5](#mysql-importing-data-any-source-load-data), vous devez invoquer le shell `mysql` à partir de l’emplacement où se trouvent les fichiers, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
## Étape 2 : Empêcher les applications d’accéder à l’instance de base de données cible
Avant de démarrer un chargement volumineux, empêchez toute activité d’application d’accéder à l’instance de base de données cible sur laquelle s’effectuera le chargement. Nous le recommandons particulièrement quand d’autres sessions sont susceptibles de modifier les tables chargées ou les tables qu’elles référencent. Cela réduit le risque de violation des contraintes intervenant pendant le chargement et améliore les performances de chargement. Dans le même temps, cela permet également de restaurer l'instance de base de données au point juste antérieur au chargement sans perdre les modifications effectuées par les processus non impliqués dans le chargement.
Il est vrai que cela peut ne pas être possible ou pratique. Si vous ne pouvez pas empêcher les applications d'accéder à l'instance de base de données avant le chargement, prenez les mesures nécessaires pour garantir la disponibilité et l'intégrité de vos données. Les étapes spécifiques requises varient grandement en fonction de cas d’utilisation spécifiques et des exigences du site.
## Étape 3 : Créer un instantané de base de données
Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, vous pouvez ignorer cette étape. Sinon, nous vous recommandons de créer des instantanés de base de données de l’instance de base de données Amazon RDS cible avant et après le chargement de données. Les instantanés de base de données Amazon RDS sont des sauvegardes complètes de votre instance de base de données qui peuvent être utilisées pour restaurer l’instance de base de données à un état connu. Lorsque vous lancez un instantané de base de données, I/O les opérations sur votre instance de base de données sont momentanément suspendues pendant la sauvegarde de votre base de données.
La création d’un instantané de base de données juste avant le chargement vous permet, si besoin est, de restaurer la base de données à son état avant le chargement. Un instantané de base de données pris immédiatement après le chargement vous évite de devoir charger les données à nouveau en cas d’incident. Vous pouvez également utiliser des instantanés de base de données après le chargement pour importer des données dans de nouvelles instances de base de données.
L'exemple suivant exécute la AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)commande pour créer un instantané de base de données de l'`AcmeRDS`instance et attribuer l'identifiant à l'instantané de base de données`"preload"`.
Pour Linux, macOS ou Unix :
```
aws rds create-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds create-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
Vous pouvez aussi utiliser la restauration de la fonctionnalité d’instantané de bases de données pour créer des instances de bases de données de test dans le but de réaliser des essais ou pour annuler les modifications effectuées pendant le chargement.
Gardez à l’esprit que la restauration d’une base de données à partir d’un instantané de bases de données crée une nouvelle instance de base de données qui, comme toutes les instances de base de données, possède un point de terminaison et un identifiant unique. Si vous devez restaurer l'instance de base de données sans modifier le point de terminaison, vous devez d'abord supprimer l'instance de base de données de telle sorte que le point de terminaison puisse être réutilisé.
Par exemple, pour créer une instance de base de données pour les essais ou autres tests, vous attribuez à l'instance de base de données son propre identifiant. Dans cet exemple, l'identifiant est `AcmeRDS-2`. L’exemple se connecte à l’instance de base de données à l’aide du point de terminaison associé à `AcmeRDS-2`. Pour plus d'informations, consultez [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html).
Pour Linux, macOS ou Unix :
```
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS-2 \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS-2 ^
--db-snapshot-identifier preload
```
Pour réutiliser le point de terminaison existant, il faut d’abord supprimer l’instance de base de données, puis donner le même identifiant à la base de données restaurée. Pour de plus amples informations, veuillez consulter [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html).
L’exemple suivant prend également un instantané de base de données final de l’instance de base de données avant de la supprimer. Cette action est facultative, mais recommandée.
Pour Linux, macOS ou Unix :
```
aws rds delete-db-instance \
--db-instance-identifier AcmeRDS \
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier AcmeRDS \
--db-snapshot-identifier preload
```
Pour Windows :
```
aws rds delete-db-instance ^
--db-instance-identifier AcmeRDS ^
--final-db-snapshot-identifier AcmeRDS-Final
aws rds restore-db-instance-from-db-snapshot ^
--db-instance-identifier AcmeRDS ^
--db-snapshot-identifier preload
```
## Étape 4 (facultative) : Désactiver les sauvegardes automatiques Amazon RDS
**Avertissement**
Ne désactivez pas les sauvegardes automatiques si vous devez effectuer une point-in-time restauration.
La désactivation des sauvegardes automatiques est une optimisation des performances et n’est pas requise pour les chargements de données. La désactivation des sauvegardes automatiques efface toutes les sauvegardes existantes. Par conséquent, une fois les sauvegardes automatisées désactivées, la point-in-time restauration n'est pas possible. Les instantanés de bases de données manuels ne sont pas affectés par la désactivation des sauvegardes automatiques. Tous les instantanés manuels de base de données existants demeurent disponibles pour la restauration.
La désactivation des sauvegardes automatiques réduit le temps de chargement de près de 25 %, ainsi que la quantité d'espace de stockage requise pendant le chargement. Si vous envisagez de charger des données dans une nouvelle instance de base de données qui ne contient aucune donnée, la désactivation des sauvegardes constitue un moyen simple d'accélérer le chargement et d'éviter d'utiliser le stockage supplémentaire nécessaire pour les sauvegardes. Cependant, dans certains cas, vous pouvez envisager de charger dans une instance de base de données qui contient déjà des données. Si tel est le cas, évaluez les avantages de la désactivation des sauvegardes par rapport à l'impact de la perte de performance point-in-time-recovery.
Les instances de bases de données ont les sauvegardes automatiques activées par défaut (avec une période de rétention égale à une journée). Pour désactiver les sauvegardes automatiques, définissez la période de rétention des sauvegardes à 0. Après le chargement, vous pouvez réactiver les sauvegardes en définissant la période de rétention des sauvegardes avec une valeur différente de zéro. Pour activer ou désactiver les sauvegardes, Amazon RDS arrête l’instance de base de données, puis la redémarre pour activer ou désactiver la journalisation MySQL.
Exécutez la AWS CLI `modify-db-instance` commande pour définir la rétention des sauvegardes sur zéro et appliquez la modification immédiatement. Comme la définition de la période de rétention à la valeur zéro nécessite un redémarrage de l’instance de base de données, attendez que le redémarrage soit terminé avant de poursuivre. Pour de plus amples informations, veuillez consulter [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html).
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--apply-immediately \
--backup-retention-period 0
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--apply-immediately ^
--backup-retention-period 0
```
Vous pouvez vérifier l'état de votre instance de base de données à l'aide de la AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande. L’exemple suivant montre comment afficher le statut de l’instance de base de données `AcmeRDS`.
```
aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"
```
Lorsque le statut de l’instance de base de données est `available`, vous êtes prêt à continuer.
## Étape 5 : Charger les données
Pour lire les lignes de vos fichiers plats dans les tables de base de données, utilisez l’instruction MySQL `LOAD DATA LOCAL INFILE`.
**Note**
Vous devez invoquer le shell `mysql` à partir de l’emplacement où se trouvent vos fichiers plats, ou utiliser le chemin absolu des fichiers lors de l’exécution de `LOAD DATA LOCAL INFILE`.
L’exemple suivant montre comment charger les données d’un fichier nommé `sales.txt` dans une table nommée `Sales` dans la base de données :
```
mysql> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\';
Query OK, 1 row affected (0.01 sec)
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
```
Pour plus d’informations sur l’instruction `LOAD DATA`, consultez [Instruction LOAD DATA](https://dev.mysql.com/doc/refman/8.4/en/load-data.html) dans la documentation MySQL.
## Étape 6 : Réactiver les sauvegardes automatiques Amazon RDS
Si vous avez désactivé les sauvegardes automatiques Amazon RDS lors de l’[étape 4](#mysql-importing-data-any-source-turn-off-automated-backups), une fois le chargement terminé, réactivez-les en redéfinissant la période de rétention des sauvegardes à la valeur qui était la sienne avant le chargement. Comme noté dans l’étape 4, Amazon RDS redémarre l’instance de base de données. Par conséquent, préparez-vous à une brève interruption de service.
L'exemple suivant exécute la AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande pour activer les sauvegardes automatiques pour l'`AcmeRDS`instance de base de données et définir la période de rétention sur un jour :
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier AcmeRDS \
--backup-retention-period 1 \
--apply-immediately
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier AcmeRDS ^
--backup-retention-period 1 ^
--apply-immediately
```
# Utilisation de la réplication MySQL dans Amazon RDS
Vous utilisez généralement des réplicas en lecture pour configurer la réplication entre instances de base de données Amazon RDS. Pour obtenir des informations générales sur les réplicas en lecture, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md). Pour obtenir des informations spécifiques sur l'utilisation des réplicas en lecture sur Amazon RDS pour MySQL, consultez la section [Utilisation de réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.md).
Vous pouvez utiliser des identificateurs de transaction globaux (GTIDs) pour la réplication avec RDS for MySQL. Pour de plus amples informations, veuillez consulter [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Vous pouvez également configurer la réplication entre une instance de base de données RDS for MySQL et une instance MariaDB ou MySQL externe à Amazon RDS. Pour plus d'informations sur la réplication de configuration avec une source externe, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
Pour chacune de ces options de réplication, vous pouvez utiliser la réplication basée sur les lignes, basée sur les instructions ou mixte. La réplication basée sur les lignes réplique uniquement les lignes modifiées à la suite d'une instruction SQL. La réplication basée sur les instructions réplique l'ensemble de l'instruction SQL. La réplication mixte utilise la réplication basée sur les instructions chaque fois que possible, mais bascule vers la réplication basée sur les lignes lorsque des instructions SQL présentant un risque pour la réplication basée sur les instructions sont exécutées. La réplication mixte est recommandée dans la plupart des cas. Le format de journalisation binaire de l'instance de base de données détermine si la réplication est basée sur les lignes, basée sur les instructions ou mixte. Pour plus d'informations sur la définition du format de journalisation binaire, consultez la section [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md).
**Note**
Vous pouvez configurer la réplication de sorte à importer des bases de données d'une instance MariaDB ou MySQL extérieure à Amazon RDS, ou à exporter des bases de données vers de telles instances. Pour plus d’informations, consultez [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Après avoir restauré votre instance de base de données à partir d'un instantané ou effectué une point-in-time restauration, vous pouvez consulter la dernière position du journal binaire récupérée depuis la base de données source dans la console RDS. Sous **Journaux et événements**, saisissez **journal binaire**. La position du journal binaire apparaît sous **Remarques relatives au système**.
**Topics**
+ [
# Utilisation de réplicas en lecture MySQL
](USER_MySQL.Replication.ReadReplicas.md)
+ [
# Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)
](mysql-replication-gtid.md)
+ [
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](MySQL.Procedural.Importing.External.Repl.md)
+ [
# Configuration multi-source-replication pour Amazon RDS for MySQL
](mysql-multi-source-replication.md)
# Utilisation de réplicas en lecture MySQL
Vous trouverez à la suite des informations spécifiques sur l'utilisation des réplicas en lecture sur RDS for MySQL. Pour obtenir des informations générales sur les réplicas en lecture et des instructions pour les utiliser, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Pour plus d’informations sur l’utilisation des réplicas en lecture MySQL, consultez les rubriques suivantes.
+ [Configuration des filtres de réplication avec MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md)
+ [Configuration de la réplication retardée avec MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md)
+ [Mise à jour des réplicas en lecture avec MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md)
+ [Utiliser des déploiements de réplicas en lecture Multi-AZ avec MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md)
+ [Utilisation de réplicas en lecture en cascade avec RDS for MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md)
+ [Surveillance du retard de réplication pour les réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.Monitor.md)
+ [Démarrage et arrêt de la réplication avec des réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.StartStop.md)
+ [Résolution d'un problème de réplica en lecture MySQL](USER_ReadRepl.Troubleshooting.md)
## Configuration des réplicas en lecture avec MySQL
Avant qu'une instance de base de données MySQL puisse être utilisée comme source de réplication, vous devez activer les sauvegardes automatiques sur l'instance de base de données source. Pour cela, vous devez définir la période de rétention des sauvegardes sur une valeur autre que 0. Cette exigence s'applique également à un réplica en lecture qui serait l'instance de base de données source d'un autre réplica en lecture. Les sauvegardes automatiques sont prises en charge pour les réplicas en lecture exécutant n'importe quelle version de MySQL. Vous pouvez configurer la réplication en fonction des coordonnées des journaux binaires pour une instance de base de données MySQL.
Vous pouvez configurer la réplication à l’aide des identifiants de transaction globaux (GTIDS) sur les versions suivantes :
+ RDS for MySQL version 5.7.44 et versions 5.7 ultérieures
+ RDS for MySQL version 8.0.28 et versions 8.0 ultérieures
+ RDS for MySQL version 8.4.3 et versions 8.4 ultérieures
Pour de plus amples informations, veuillez consulter [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données au sein de la même région. Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, faites-le également pour les réplicas en lecture.
RDS for MySQL prend en charge les réplicas en lecture en cascade. Pour apprendre à configurer des réplicas en lecture en cascade, consultez [Utilisation de réplicas en lecture en cascade avec RDS for MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md).
Vous pouvez exécuter simultanément plusieurs actions de création et suppression de réplicas en lecture qui référencent la même instance de base de données source. Lorsque vous effectuez ces actions, restez dans la limite de 15 réplicas en lecture pour chaque instance source.
Un réplica en lecture d'une instance de base de données MySQL ne peut pas utiliser une version de moteur de base de données inférieure à son instance de base de données source.
### Préparation des instances de base de données MySQL qui utilisent MyISAM
Si votre instance de base de données MySQL utilise un moteur non transactionnel tel que MyISAM, vous devez effectuer les étapes suivantes pour configurer correctement votre réplica en lecture. Ces étapes sont nécessaires pour vous assurer que le réplica en lecture dispose d'une copie cohérente de vos données. Ces étapes ne sont pas nécessaires si toutes vos tables utilisent un moteur transactionnel comme InnoDB.
1. Arrêtez toutes les opérations DML (Data Manipulation Language) et DDL (Data Definition Language) sur les tables non transactionnelles dans l'instance de bases de données source et attendez qu'elles se terminent. Les instructions SELECT peuvent continuer à fonctionner.
1. Videz et verrouillez les tables dans l'instance de bases de données source.
1. Créez le réplica en lecture en suivant l'une des méthodes présentées dans les sections suivantes.
1. Vérifiez l'avancement de la création du réplica en lecture en utilisant, par exemple, l'opération d'API `DescribeDBInstances`. Une fois que le réplica en lecture est disponible, déverrouillez les tables de l'instance de base de données source et reprenez les opérations de base de données normales.
# Configuration des filtres de réplication avec MySQL
Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec un réplica en lecture. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les exclure de la réplication.
Voici quelques cas d’utilisation pour les filtres de réplication :
+ Pour réduire la taille d’un réplica en lecture. Avec le filtrage de réplication, vous pouvez exclure les bases de données et les tables qui ne sont pas nécessaires sur le réplica en lecture.
+ Pour exclure des bases de données et des tables des réplicas en lecture, pour des raisons de sécurité.
+ Pour répliquer différentes bases de données et tables pour des cas d’utilisation spécifiques au niveau de différents réplicas en lecture. Par exemple, vous pouvez utiliser des réplicas en lecture spécifiques pour l’analyse ou le partage.
+ Pour une instance de base de données qui a lu des répliques dans différentes bases de données Régions AWS, pour répliquer différentes bases de données ou tables dans différentes. Régions AWS
**Note**
Vous pouvez également utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une instance de base de données MySQL principale configurée en tant que réplica dans une topologie de réplication entrante. Pour en savoir plus sur cette configuration, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [
## Définition des paramètres de filtrage de la réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [
## Limites du filtrage de réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [
## Exemples de filtrage de réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [
## Affichage des filtres de réplication pour un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Définition des paramètres de filtrage de la réplication pour RDS for MySQL
Pour configurer des filtres de réplication, définissez les paramètres de filtrage de réplication suivants sur le réplica en lecture :
+ `replicate-do-db` : répliquer les modifications apportées aux bases de données spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les bases de données spécifiées dans le paramètre sont répliquées.
+ `replicate-ignore-db` : ne pas répliquer les modifications apportées aux bases de données spécifiées. Lorsque le paramètre `replicate-do-db` est défini pour un réplica en lecture, ce paramètre n'est pas évalué.
+ `replicate-do-table` : répliquer les modifications apportées aux tables spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les tables spécifiées dans le paramètre sont répliquées. En outre, lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d'inclure la base de données qui comprend les tables spécifiées dans la réplication avec le réplica en lecture.
+ `replicate-ignore-table` : ne pas répliquer les modifications apportées aux tables spécifiées. Lorsque le paramètre `replicate-do-table` est défini pour un réplica en lecture, ce paramètre n'est pas évalué.
+ `replicate-wild-do-table` : répliquer les tables en fonction des modèles de nom de base de données et nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d'inclure la base de données qui comprend les tables spécifiées dans la réplication avec le réplica en lecture.
+ `replicate-wild-ignore-table` : ne pas répliquer les tables en fonction des modèles de nom de base de données et de nom de table spécifiés. Les caractères génériques `%` et `_` sont pris en charge. Lorsque le paramètre `replicate-do-table` ou `replicate-wild-do-table` est défini pour un réplica en lecture, ce paramètre n'est pas évalué.
Les paramètres sont évalués dans l'ordre dans lequel ils sont répertoriés. Pour plus d’informations sur le fonctionnement de ces paramètres, consultez la documentation MySQL :
+ Pour plus d’informations générales, voir [ Options et variables du serveur de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html).
+ Pour plus d’informations sur la façon dont les paramètres de filtrage de réplication de base de données sont évalués, voir [ Évaluation des options de réplication au niveau de la base de données et des options de la journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html).
+ Pour plus d’informations sur l’évaluation des paramètres de filtrage de réplication de table, reportez-vous à la section [ Évaluation des options de réplication au niveau de la table](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html).
Par défaut, chacun de ces paramètres a une valeur vide. Sur chaque réplica en lecture, vous pouvez utiliser ces paramètres pour définir, modifier et supprimer des filtres de réplication. Lorsque vous définissez l'un de ces paramètres, séparez chaque filtre des autres par une virgule.
Vous pouvez utiliser les caractères génériques `%` et `_` dans les paramètres `replicate-wild-do-table` et `replicate-wild-ignore-table`. Le caractère générique `%` correspond à un nombre quelconque de caractères, et le caractère générique `_` ne correspond qu’à un seul caractère.
Le format de journalisation binaire de l’instance de base de données source est important pour la réplication, car il détermine l’enregistrement des modifications de données. Le réglage du paramètre `binlog_format` détermine si la réplication est basée sur les lignes ou les instructions. Pour plus d’informations, consultez [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md).
**Note**
Toutes les instructions DDL (Data Definition Language) sont répliquées en tant qu’instructions, quel que soit le paramètre `binlog_format` de l’instance de base de données source.
## Limites du filtrage de réplication pour RDS for MySQL
Les limites suivantes s'appliquent au filtrage de réplication pour RDS for MySQL :
+ Chaque paramètre de filtrage de réplication a une limite de 2 000 caractères.
+ Les virgules ne sont pas prises en charge dans les filtres de réplication pour les valeurs de paramètres. Dans une liste de paramètres, les virgules ne peuvent être utilisées que comme séparateurs de valeurs. Par exemple, `ParameterValue='`a,b`'` est pris en charge, mais `ParameterValue='a,b'` ne l’est pas.
+ Les options `--binlog-do-db` et `--binlog-ignore-db` de MySQL pour le filtrage des journaux binaires ne sont pas prises en charge.
+ Le filtrage de réplication ne prend pas en charge les transactions XA.
Pour plus d'informations, consultez la section [Restrictions on XA Transactions (Restrictions sur les transactions XA)](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) dans la documentation MySQL.
## Exemples de filtrage de réplication pour RDS for MySQL
Pour configurer le filtrage de réplication pour un réplica en lecture, modifiez les paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
**Note**
Vous ne pouvez pas modifier un groupe de paramètres par défaut. Si le réplica en lecture utilise un groupe de paramètres par défaut, créez un nouveau groupe de paramètres et associez-le au réplica en lecture. Pour plus d'informations sur les groupes de paramètres de base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez définir les paramètres d'un groupe de paramètres à l'aide de l'API AWS Management Console AWS CLI, ou RDS. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Lorsque vous définissez des paramètres dans un groupe de paramètres, toutes les instances de base de données associées au groupe de paramètres utilisent les réglages des paramètres. Si vous définissez les paramètres de filtrage de réplication dans un groupe de paramètres, assurez-vous que le groupe de paramètres est associé uniquement aux réplicas en lecture. Laissez les paramètres de filtrage de réplication vides pour les instances de base de données source.
Les exemples suivants définissent les paramètres à l’aide de la AWS CLI. Ces exemples définissent `ApplyMethod` sur `immediate` de sorte que les modifications de paramètre se produisent immédiatement après la fin de la commande de la CLI. Si vous souhaitez qu’une modification en attente soit appliquée après le redémarrage du réplica en lecture, définissez `ApplyMethod` sur `pending-reboot`.
Les exemples suivants définissent des filtres de réplication :
+ [Including databases in replication](#rep-filter-in-dbs-mysql)
+ [Including tables in replication](#rep-filter-in-tables-mysql)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mysql)
+ [Excluding tables from replication](#rep-filter-ex-tables-mysql)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql)
**Example Inclusion de bases de données dans la réplication**
L’exemple suivant inclut les bases de données `mydb1` et `mydb2` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
```
**Example Inclusion de tables dans la réplication**
L’exemple suivant inclut les tables `table1` et `table2` dans la base de données `mydb1` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
```
**Example Inclusion de tables dans la réplication à l’aide de caractères génériques**
L’exemple suivant inclut des tables dont les noms commencent par `order` et `return` dans la base de données `mydb` dans la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
```
**Example Exclusion de bases de données de la réplication**
L’exemple suivant exclut les bases de données `mydb5` et `mydb6` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
```
**Example Exclusion de tables de la réplication**
L’exemple suivant exclut les tables `table1` dans la base de données `mydb5` et `table2` dans la base de données `mydb6` de la réplication.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
```
**Example Exclusion de tables de la réplication à l’aide des caractères génériques**
L’exemple suivant exclut de la réplication les tables dont les noms commencent par `order` et `return` dans la base de données `mydb7`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myparametergroup ^
--parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
```
## Affichage des filtres de réplication pour un réplica en lecture
Vous pouvez afficher les filtres de réplication pour un réplica en lecture de la manière suivante :
+ Vérifiez les réglages des paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.
Pour obtenir des instructions, consultez [Affichage des valeurs de paramètres pour un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
+ Dans un client MySQL, connectez-vous au réplica en lecture et exécutez l’instruction `SHOW REPLICA STATUS`.
Dans la sortie, les champs suivants affichent les filtres de réplication pour le réplica en lecture :
+ `Replicate_Do_DB`
+ `Replicate_Ignore_DB`
+ `Replicate_Do_Table`
+ `Replicate_Ignore_Table`
+ `Replicate_Wild_Do_Table`
+ `Replicate_Wild_Ignore_Table`
Pour plus d’informations sur ces champs, consultez [Vérification du statut de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) dans la documentation MySQL.
# Configuration de la réplication retardée avec MySQL
Vous pouvez utiliser la réplication retardée comme stratégie pour la reprise après sinistre. Avec la réplication retardée, vous spécifiez la durée minimale, en secondes, pour retarder la réplication de la source vers la réplique de lecture. En cas de sinistre, par exemple la suppression accidentelle d'une table, vous appliquez la procédure suivante pour reprendre rapidement après le sinistre :
+ Arrêtez la réplication vers le réplica en lecture avant que lui soit envoyée la modification qui a provoqué le sinistre.
Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
+ Arrêtez la réplication et précisez qu'elle doit s'arrêter automatiquement à une position donnée dans un fichier journal.
Vous indiquez une position juste avant le sinistre grâce à la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
+ Effectuez la promotion du réplica en lecture pour qu'il devienne la nouvelle instance de base de données source, en suivant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
**Note**
Sur RDS for MySQL 8.4, la réplication retardée est prise en charge pour MySQL 8.4.3 et versions ultérieures. Sur RDS for MySQL 8.0, la réplication retardée est prise en charge pour MySQL 8.0.28 et versions ultérieures. Sur RDS for MySQL 5.7, la réplication retardée est prise en charge pour MySQL 5.7.44 et versions ultérieures.
Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer la réplication différée avec AWS Management Console AWS CLI, l'API ou l'API Amazon RDS.
Vous pouvez utiliser la réplication basée sur les identificateurs de transaction globaux (GTIDs) dans une configuration de réplication différée pour les versions suivantes :
RDS for MySQL version 5.7.44 et versions 5.7 ultérieures
RDS for MySQL version 8.0.28 et versions 8.0 ultérieures
RDS for MySQL version 8.4.3 et versions 8.4 ultérieures
Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) au lieu de la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
**Topics**
+ [
## Configuration de la réplication retardée pendant la création du réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [
## Modification de la réplication retardée pour un réplica en lecture existant
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [
## Définition d'une position où arrêter la réplication vers un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil)
+ [
## Promotion d’un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.Promote)
## Configuration de la réplication retardée pendant la création du réplica en lecture
Pour configurer la réplication retardée pour tout réplica en lecture à venir créé à partir d'une instance de base de données, exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
**Pour configurer la réplication retardée pendant la création du réplica en lecture**
1. À l'aide d'un client MySQL, connectez-vous à l'instance de base de données MySQL qui constituera la source des réplicas en lecture en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication est retardée d'au moins une heure (3 600 secondes) pour tout réplica en lecture créé à partir de l'instance de base de données actuelle.
```
call mysql.rds_set_configuration('target delay', 3600);
```
**Note**
Après avoir exécuté cette procédure stockée, toute réplique de lecture que vous créez à l' AWS CLI aide de l'API Amazon RDS est configurée avec un délai de réplication du nombre de secondes spécifié.
## Modification de la réplication retardée pour un réplica en lecture existant
Pour modifier la réplication retardée pour un réplica en lecture existant, exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
**Pour modifier la réplication retardée pour un réplica en lecture existant**
1. En utilisant un client MySQL, connectez-vous au réplica en lecture en tant qu'utilisateur principal.
1. Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication vers le réplica en lecture est retardée d'au moins une heure (3 600 secondes).
```
call mysql.rds_set_source_delay(3600);
```
1. Utilisez la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour lancer la réplication.
## Définition d'une position où arrêter la réplication vers un réplica en lecture
Après avoir arrêté la réplication vers le réplica en lecture, vous pouvez démarrer la réplication, puis l'arrêter à la position spécifiée dans le fichier journal binaire en utilisant la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
**Pour démarrer la réplication vers un réplica en lecture et l'arrêter à une position donnée**
1. En utilisant un client MySQL, connectez-vous à l'instance de base de données MySQL source en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position `120` dans le fichier journal binaire `mysql-bin-changelog.000777`. Dans un scénario de reprise après sinistre, nous supposons que cette position `120` est juste avant le sinistre.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
La réplication s’arrête automatiquement lorsque le point d’arrêt est atteint. L’événement RDS suivant est généré: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`.
## Promotion d’un réplica en lecture
Après l'arrêt de la réplication, dans un scénario de reprise après sinistre, vous pouvez promouvoir un réplica en lecture comme nouvelle instance de base de données source. Pour de plus amples informations sur la promotion d'un réplica en lecture, veuillez consulter [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Mise à jour des réplicas en lecture avec MySQL
Les réplicas en lecture sont conçus pour prendre en charge les requêtes de lecture, mais vous pouvez avoir besoin de mises à jour ponctuelles. À titre d'exemple, vous pouvez avoir besoin d'ajouter un index, pour optimiser les types spécifiques de requêtes qui accèdent au réplica.
Bien que vous puissiez activer les mises à jour en définissant le paramètre `read_only` sur `0` dans le groupe de paramètres de base de données pour le réplica en lecture, nous vous recommandons de ne pas le faire car cela peut poser des problèmes si le réplica en lecture devient incompatible avec l'instance de base de données source. Pour les opérations de maintenance, nous vous recommandons d'utiliser blue/green des déploiements. Pour de plus amples informations, veuillez consulter [Utilisation des Blue/Green déploiements pour les mises à jour de bases de](blue-green-deployments.md).
Si vous désactivez la lecture seule sur un réplica en lecture, modifiez la valeur du paramètre `1` pour rétablir `read_only` dès que possible.
# Utiliser des déploiements de réplicas en lecture Multi-AZ avec MySQL
Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou multi-AZ. Vous utilisez des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, mais vous ne pouvez pas utiliser une instance secondaire multi-AZ pour servir les requêtes en lecture seule. À la place, vous pouvez créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Si l'instance source d'un déploiement multi-AZ bascule vers l'instance secondaire, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance secondaire (désormais principale) comme source de réplication. Pour plus d'informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
Vous pouvez créer un réplica en lecture en tant qu'instance de base de données Multi-AZ. Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité pour la prise en charge du basculement pour le réplica. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
# Utilisation de réplicas en lecture en cascade avec RDS for MySQL
RDS for MySQL prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l'échelle les lectures sans surcharger votre instance de base de données RDS for MySQL source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS for MySQL envoie des données au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite les données au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l'instance de base de données RDS for MySQL, sans surcharger uniquement l'instance de base de données source.
Vous pouvez créer une série comportant jusqu'à trois réplicas en lecture dans une chaîne à partir d'une instance de base de données RDS for MySQL source. Par exemple, supposons que vous disposez d'une instance de base de données RDS for MySQL, `mysql-main`. Vous pouvez effectuer les actions suivantes :
+ À partir de `mysql-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `mysql-main`. Une série complète d'instances allant d'une instance de base de données source RDS for MySQL jusqu'à la fin d'une série de réplicas en lecture en cascade peut comporter au plus quatre instances de base de données.
Pour que les réplicas en lecture en cascade fonctionnent, les sauvegardes automatisées doivent être activées sur chaque instance de base de données RDS for MySQL. Pour activer les sauvegardes automatiques sur un réplica en lecture, commencez par créer le réplica en lecture, puis modifiez-le pour activer les sauvegardes automatiques. Pour plus d’informations, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d’une cascade. La promotion d’un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `mysql-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l’exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s’agit désormais d’une instance de base de données en lecture/écriture complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `mysql-main` continue la réplication sur `read-replica-1`.
Pour plus d’informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Surveillance du retard de réplication pour les réplicas en lecture MySQL
Pour les réplicas en lecture MySQL, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS `ReplicaLag`. La métrique `ReplicaLag` contient la valeur du champ `Seconds_Behind_Master` de la commande `SHOW REPLICA STATUS`.
Les causes courantes du retard de réplication pour MySQL sont les suivantes :
+ Une indisponibilité du réseau.
+ L'écriture dans des tables avec des index différents sur un réplica en lecture. Si le paramètre `read_only` est défini sur `0` sur le réplica en lecture, la réplication peut être rompue si le réplica en lecture devient incompatible avec l'instance de base de données source. Une fois que vous avez effectué les tâches de maintenance sur le réplica en lecture, nous vous recommandons de définir à nouveau le paramètre `read_only` sur `1`.
+ Utilisation d’un moteur de stockage non transactionnel tel que MyISAM. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MySQL.
Lorsque la métrique `ReplicaLag` atteint 0, le réplica a rattrapé le retard sur l’instance de base de données source. Si la métrique `ReplicaLag` retourne -1, la réplication n’est actuellement pas active. `ReplicaLag`= -1 est équivalent à `Seconds_Behind_Master` = `NULL`.
# Démarrage et arrêt de la réplication avec des réplicas en lecture MySQL
Vous pouvez arrêter et redémarrer le processus de réplication sur une instance de base de données Amazon RDS en appelant les procédures stockées système [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Vous pouvez procéder ainsi lors d'une réplication entre deux instances Amazon RDS pour des opérations de longue durée, telles que la création d'un grand index. Vous devez également arrêter et démarrer la réplication lors de l'importation ou de l'exportation de bases de données. Pour plus d’informations, consultez [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Si la réplication est arrêtée pendant plus de 30 jours consécutifs, manuellement ou en raison d'une erreur de réplication, Amazon RDS met fin à la réplication entre l'instance de base de données source et tous les réplicas en lecture. Cela permet d'éviter l'augmentation des besoins en stockage sur l'instance de bases de données source et d'importants délais de basculement. L'instance de base de données du réplica en lecture est toujours disponible. En revanche, la réplication ne peut pas être reprise, car les journaux binaires requis par le réplica en lecture sont supprimés de l'instance de base de données source une fois la réplication terminée. Vous pouvez créer un nouveau réplica en lecture pour l'instance de base de données source afin de rétablir la réplication.
# Résolution d'un problème de réplica en lecture MySQL
Dans certains cas, pour les instances de base de données, les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source. Ce problème survient quand des événements de journaux binaires ou des journaux redo InnoDB ne sont pas vidés lors d'une panne du réplica en lecture ou de l'instance de base de données source. Dans ces situations, supprimez et recréez manuellement les réplicas en lecture. Vous pouvez réduire la probabilité que cela se produise en définissant les valeurs de paramètre suivantes : `sync_binlog=1` et `innodb_flush_log_at_trx_commit=1`. Ces paramètres peuvent réduire les performances. Testez donc leur impact avant d’implémenter les modifications dans un environnement de production.
**Avertissement**
Dans le groupe de paramètres associé à l'instance de base de données source, nous recommandons de conserver ces valeurs de paramètres : `sync_binlog=1` et `innodb_flush_log_at_trx_commit=1`. Ces paramètres sont dynamiques. Si vous ne souhaitez pas utiliser ces paramètres, nous vous recommandons de définir temporairement ces valeurs avant d'exécuter toute opération sur l'instance de base de données source susceptible de provoquer son redémarrage. Ces opérations incluent, sans s'y limiter, le redémarrage, le redémarrage avec basculement, la mise à niveau de la version de la base de données et la modification de la classe d'instance de base de données ou de son stockage. La même recommandation s'applique à la création de nouveaux réplicas en lecture pour l'instance de base de données source.
Le non-respect de ces instructions augmente le risque que les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source.
Les technologies de réplication pour MySQL sont asynchrones. Parce qu’elles sont asynchrones, des augmentations occasionnelles de `BinLogDiskUsage` sur l’instance de base de données source et `ReplicaLag` sur le réplica en lecture sont prévisibles. Par exemple, un volume élevé d’opérations d’écriture sur l’instance de bases de données source peut se produire en parallèle. Tandis que les opérations d’écritures sur le réplica en lecture sont sérialisées à l’aide d’un seul thread d’I/O, ce qui peut conduire à un retard entre l’instance source et le réplica. Pour plus d’informations sur les réplicas en lecture seule dans la documentation MySQL, consultez [Détails d’implémentation de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html).
Vous pouvez effectuer plusieurs opérations pour réduire le retard entre les mises à jour d’une instance de base de données source et les mises à jour suivantes appliquées au réplica en lecture, telles que les opérations suivantes :
+ Dimensionnement d’un réplica en lecture pour qu’il ait une taille de stockage et une classe d’instance de base de données comparables à celles de l’instance de base de données source.
+ Garantie que les réglages des paramètres dans les groupes de paramètres de base de données utilisés par l’instance de base de données source et le réplica en lecture sont compatibles. Pour obtenir plus d’informations et un exemple, reportez-vous à la présentation du paramètre `max_allowed_packet`, plus loin dans cette section.
Amazon RDS surveille l’état de réplication de vos réplicas en lecture et met à jour le champ `Replication State` de l’instance du réplica en lecture avec la valeur `Error` si la réplication s’arrête pour une raison quelconque. Par exemple, dans le cas de requêtes DML exécutées sur votre réplica en lecture qui sont en conflit avec les mises à jour effectuées sur l’instance de base de données source.
Vous pouvez passer en revue les détails de l'erreur associée et déclenchée par le moteur MySQL, en consultant le champ `Replication Error`. Des événements indiquant l’état du réplica en lecture sont également générés, y compris [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) et [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Pour plus d’informations sur les événements et l’abonnement aux événements, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md). Si un message d'erreur MySQL est renvoyé, passez en revue le numéro de l'erreur dans la [documentation sur les messages d'erreur MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html).
Un problème courant susceptible de causer des erreurs de réplication se pose lorsque la valeur du paramètre `max_allowed_packet` d’un réplica en lecture est inférieure à celle du paramètre `max_allowed_packet` de l’instance de base de données source. Le paramètre `max_allowed_packet` est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres de base de données. Vous utilisez `max_allowed_packet` pour spécifier la taille maximale du code DML qui peut être exécuté sur la base de données. Dans certains cas, la valeur `max_allowed_packet` du groupe de paramètres de base de données associé à un réplica en lecture est inférieure à la valeur `max_allowed_packet` du groupe de paramètres de base de données associé à l'instance de base de données source. Dans ces cas, le processus de réplication peut lancer l'erreur `Packet bigger than 'max_allowed_packet' bytes` et arrêter la réplication. Pour corriger cette erreur, faites en sorte que l'instance de base de données source et le réplica en lecture utilisent des groupes de paramètres de base de données avec les mêmes valeurs pour le paramètre `max_allowed_packet`.
Voici d’autres situations courantes susceptibles de causer des erreurs de réplication :
+ Écriture sur les tables d’un réplica en lecture. Dans certains cas, vous pouvez créer des index sur un réplica en lecture différents des index sur l'instance de base de données source. Vous devez alors définir le paramètre `read_only` sur `0` pour créer les index. Si vous écrivez dans des tables sur le réplica en lecture, cela peut interrompre la réplication si le réplica en lecture devient incompatible avec l'instance de base de données source. Une fois que vous avez effectué les tâches de maintenance sur le réplica en lecture, nous vous recommandons de définir à nouveau le paramètre `read_only` sur `1`.
+ Utilisation d'un moteur de stockage non transactionnel tel que MyISAM. Les réplicas en lecture nécessitent un moteur de stockage transactionnel. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MySQL.
+ Utilisation de requêtes non déterministes non sécurisées telles que `SYSDATE()`. Pour plus d’informations, consultez [Determination of safe and unsafe statements in binary logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
Si vous décidez que vous pouvez ignorer une erreur en toute sécurité, vous pouvez suivre la procédure décrite dans la section [Ignorer une erreur de réplication pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Sinon, vous pouvez d'abord supprimer le réplica en lecture. Vous créez ensuite une instance à l'aide du même identifiant d'instance de base de données, de telle sorte que le point de terminaison demeure le même que celui de votre ancien réplica en lecture. Si une erreur de réplication est corrigée, le champ `Replication State` prend la valeur *replicating (réplication en cours)*.
# Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)
Le contenu ci-dessous explique comment utiliser les identifiants de transaction globaux (GTID) avec la réplication des journaux binaires (binlog) entre les instances de base de données Amazon RDS for MySQL.
Si vous utilisez la réplication des journaux binaires, mais que vous ne maîtrisez pas la réplication GTID avec MySQL, consultez [Réplication avec des identifiants de transaction globaux](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) dans la documentation MySQL.
La réplication basée sur GTID est prise en charge pour les versions suivantes :
+ Toutes les versions RDS for MySQL 8.4
+ Toutes les versions RDS for MySQL 8.0
+ Toutes les versions RDS for MySQL 5.7
Toutes les instances de base de données MySQL dans une configuration de réplication doivent respecter cette exigence de version.
**Topics**
+ [
## Présentation des identifiants de transaction globaux (GTID)
](#mysql-replication-gtid.overview)
+ [
## Paramètres pour la réplication basée sur des identifiants de transaction globaux (GTID)
](#mysql-replication-gtid.parameters)
+ [
# Activation de la réplication GTID sur les nouveaux réplicas en lecture dans RDS for MySQL
](mysql-replication-gtid.configuring-new-read-replicas.md)
+ [
# Activation de la réplication GTID sur les réplicas en lecture existants dans RDS for MySQL
](mysql-replication-gtid.configuring-existing-read-replicas.md)
+ [
# Désactivation de la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture
](mysql-replication-gtid.disabling.md)
## Présentation des identifiants de transaction globaux (GTID)
Les *identifiants de transaction globaux (GTID)* sont des identifiants uniques générés pour des transactions MySQL validées. Vous pouvez utiliser ces identifiants pour simplifier et faciliter la résolution des problèmes liés à la réplication des journaux binaires.
MySQL utilise deux types différents de transactions pour la réplication des journaux binaires :
+ *Transactions GTID* – Transactions identifiées par un identifiant de transaction global (GTID).
+ *Transactions anonymes* – Transactions auxquelles aucun identifiant de transaction global (GTID) n'est associé.
Dans une configuration de réplication, les GTID sont uniques parmi toutes les instances de base de données. Les GTID simplifient la configuration de réplication dans la mesure où, lorsque vous les utilisez, vous n'avez pas à vous référer aux positions des fichiers journaux. Les GTID facilitent également le suivi des transactions répliquées et déterminent si l'instance source et les réplicas sont cohérents.
Vous pouvez utiliser la réplication basée sur GTID pour répliquer des données avec des réplicas en lecture RDS for MySQL. Vous pouvez configurer une réplication GTID lorsque vous créez de nouveaux réplicas en lecture, ou convertir des réplicas en lecture existants pour utiliser la réplication GTID.
Vous pouvez également utiliser la réplication GTID dans une configuration de réplication retardée avec RDS for MySQL. Pour plus d’informations, consultez [Configuration de la réplication retardée avec MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md).
## Paramètres pour la réplication basée sur des identifiants de transaction globaux (GTID)
Utilisez les paramètres suivants pour configurer une réplication GTID.
| Paramètre | Valeurs valides | Description |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` spécifie que les nouvelles transactions sont des transactions anonymes (et n'ont donc pas de GTID), et qu'une transaction doit être anonyme pour être répliquée. `OFF_PERMISSIVE` spécifie que les nouvelles transactions sont des transactions anonymes, mais que toutes les transactions peuvent être répliquées. `ON_PERMISSIVE` spécifie que les nouvelles transactions sont des transactions GTID, mais que toutes les transactions peuvent être répliquées. `ON` spécifie que les nouvelles transactions sont des transactions GTID, et qu'une transaction doit être une transaction GTID pour être répliquée. |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` autorise les transactions à enfreindre la cohérence GTID. `ON` interdit aux transactions d'enfreindre la cohérence GTID. `WARN` autorise les transactions à enfreindre la cohérence GTID mais génère un avertissement lorsqu'une infraction se produit. |
**Note**
Dans AWS Management Console, le paramètre `gtid_mode` apparaît sous la forme `gtid-mode`.
Pour la réplication GTID, utilisez ces paramètres pour le groupe de paramètres de votre instance de base de données ou de votre réplica en lecture :
+ `ON` et `ON_PERMISSIVE` s'appliquent uniquement à la réplication sortante à partir d'une instance de base de données RDS. Ces deux valeurs font que votre instance de base de données RDS utilise les GTID pour les transactions qui sont répliquées. `ON` exige que la base de données cible utilise également la réplication basée sur les GTID. `ON_PERMISSIVE` rend la réplication basée sur les GTID facultative sur la base de données cible.
+ S'il est défini, `OFF_PERMISSIVE` indique que vos instances de base de données RDS peuvent accepter la réplication entrante d'une base de données source. Elles peuvent le faire indépendamment du fait que la base de données source utilise ou non la réplication basée sur les GTID.
+ S'il est défini, `OFF` indique que votre instance de base de données RDS n'accepte que la réplication entrante des bases de données sources qui n'utilisent pas la réplication basée sur les GTID.
Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
# Activation de la réplication GTID sur les nouveaux réplicas en lecture dans RDS for MySQL
Lorsque la réplication GTID est activée pour une instance de base de données RDS for MySQL, elle est configurée automatiquement pour les réplicas en lecture de l’instance de base de données.
**Pour activer la réplication GTID pour des nouveaux réplicas en lecture**
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données contient la configuration de paramètres suivante :
+ `gtid_mode` : `ON` ou `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
Pour plus d’informations sur la définition des paramètres de configuration à l’aide de groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Pour en savoir plus à ce sujet, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Créez un ou plusieurs réplicas en lecture de l’instance de base de données. Pour en savoir plus à ce sujet, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Amazon RDS tente d’établir une réplication GTID entre l’instance de base de données MySQL et les réplicas en lecture à l’aide du paramètre `MASTER_AUTO_POSITION`. En cas d’échec, Amazon RDS utilise les positions de fichiers journaux pour la réplication avec les réplicas en lecture. Pour plus d’informations sur le paramètre `MASTER_AUTO_POSITION`, consultez la page [GTID Auto-Positioning](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) dans la documentation MySQL.
# Activation de la réplication GTID sur les réplicas en lecture existants dans RDS for MySQL
Pour une instance de base de données MySQL existante avec des réplicas en lecture qui n’utilise pas la réplication GTID, vous pouvez configurer la réplication GTID entre l’instance de base de données et les réplicas en lecture.
**Pour activer la réplication GTID pour des réplicas en lecture existants**
1. Si l’instance de base de données ou un réplica en lecture utilise une version 8.0 de RDS for MySQL inférieure à la version 8.0.26, mettez à niveau l’instance de base de données ou le réplica en lecture vers la version 8.0.26 ou une version supérieure de MySQL 8.0. Toutes les versions de RDS for MySQL 8.4 et 5.7 prennent en charge la réplication GTID.
Pour plus d’informations, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
1. (Facultatif) Réinitialisez les paramètres GTID et testez le comportement de l’instance de base de données et des réplicas en lecture :
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient le paramètre `enforce_gtid_consistency` défini sur `WARN`.
Pour plus d’informations sur la définition des paramètres de configuration à l’aide de groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Si vous modifiez le groupe de paramètres pour un réplica en lecture, redémarrez celui-ci.
Pour plus d’informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Exécutez votre instance de base de données et vos réplicas en lecture avec votre charge de travail normale et surveillez les fichiers journaux.
Si vous recevez des avertissements relatifs à des transactions incompatibles avec les identifiants de transaction globaux, modifiez votre application de sorte qu’elle utilise uniquement des fonctions compatibles avec les identifiants de transaction globaux. Assurez-vous que l’instance de base de données ne génère aucun avertissement relatif à des transactions incompatibles avec les identifiants de transaction globaux avant de passer à l’étape suivante.
1. Réinitialisez les paramètres GTID de la réplication basée sur des identifiants de transaction globaux qui autorise les transactions anonymes jusqu’à ce que les réplicas en lecture les aient toutes traitées.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Si vous modifiez le groupe de paramètres pour un réplica en lecture, redémarrez celui-ci.
1. Attendez que toutes vos transactions anonymes soient répliquées. Pour vérifier qu’elles ont été répliquées, procédez comme suit :
1. Exécutez l’instruction suivante sur votre instance de base de données source.
**MySQL 8.4**
```
SHOW BINARY LOG STATUS;
```
**MySQL 5.7 et 8.0**
```
SHOW MASTER STATUS;
```
Notez les valeurs dans les colonnes `File` et `Position`.
1. Sur chaque réplica en lecture, utilisez les informations de fichier et de position de l’instance source lors de l’étape précédente pour exécuter la requête suivante.
```
SELECT MASTER_POS_WAIT('file', position);
```
Par exemple, si votre fichier se nomme `mysql-bin-changelog.000031` et que sa position est `107`, exécutez l’instruction suivante.
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
Si le réplica en lecture a dépassé la position spécifiée, la requête renvoie immédiatement un résultat. Sinon, la fonction attend. Passez à l’étape suivante lorsque la requête a renvoyé un résultat pour tous les réplicas en lecture.
1. Réinitialisez les paramètres GTID uniquement pour la réplication GTID.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `ON`
+ `enforce_gtid_consistency` – `ON`
1. Redémarrez l’instance de base de données et chaque réplica en lecture.
1. Sur chaque réplica en lecture, exécutez la procédure suivante.
**Versions majeures MySQL 8.4 et ultérieures**
```
CALL mysql.rds_set_source_auto_position(1);
```
**Versions majeures MySQL 8.0 et antérieures**
```
CALL mysql.rds_set_master_auto_position(1);
```
# Désactivation de la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture
Vous pouvez désactiver la réplication GTID pour un une instance de base de données MySQL avec des réplicas en lecture.
**Pour désactiver la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture**
1. Sur chaque réplica en lecture, exécutez la procédure suivante :
**Versions majeures MySQL 8.4 et ultérieures**
```
CALL mysql.rds_set_source_auto_position(0);
```
**Versions majeures MySQL 8.0 et antérieures**
```
CALL mysql.rds_set_master_auto_position(0);
```
1. Réinitialisez `gtid_mode` sur `ON_PERMISSIVE`.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données MySQL et à chaque réplica en lecture contient le paramètre `gtid_mode` défini sur `ON_PERMISSIVE`.
Pour plus d’informations sur la définition des paramètres de configuration à l’aide de groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture. Pour plus d’informations sur le redémarrage, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Réinitialisez `gtid_mode` sur `OFF_PERMISSIVE`.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données MySQL et à chaque réplica en lecture contient le paramètre `gtid_mode` défini sur `OFF_PERMISSIVE`.
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture.
1. Attendez que toutes les transactions GTID soient appliquées sur tous les réplicas en lecture. Pour vérifier qu’elles ont été appliquées, procédez comme suit :
1. Exécutez la commande suivante sur l’instance de base de données MySQL :
**MySQL 8.4**
```
SHOW BINARY LOG STATUS
```
**MySQL 5.7 et 8.0**
```
SHOW MASTER STATUS
```
Votre sortie doit ressembler à ce qui suit.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
Notez le fichier et la position dans votre sortie.
1. Sur chaque réplica en lecture, utilisez les informations de fichier et de position de l’instance source lors de l’étape précédente pour exécuter la requête suivante :
**MySQL 8.4, ainsi que MySQL 8.0.26 et les versions ultérieures de MySQL**
```
SELECT SOURCE_POS_WAIT('file', position);
```
**MySQL 5.7**
```
SELECT MASTER_POS_WAIT('file', position);
```
Par exemple, si votre fichier se nomme `mysql-bin-changelog.000031` et que sa position est `107`, exécutez l’instruction suivante :
**MySQL 8.4, ainsi que MySQL 8.0.26 et les versions ultérieures de MySQL**
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
**MySQL 5.7**
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. Réinitialisez les paramètres GTID pour désactiver la réplication GTID.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données MySQL et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture.
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Vous pouvez configurer la réplication entre une instance de base de données RDS for MySQL ou MariaDB et une instance MySQL ou MariaDB externe à Amazon RDS en utilisant la réplication de fichiers journaux binaires.
**Topics**
+ [
## Avant de commencer
](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](#MySQL.Procedural.Importing.External.Repl.Procedure)
## Avant de commencer
Vous pouvez configurer la réplication en utilisant la position du fichier journal binaire des transactions répliquées.
Les autorisations requises pour démarrer la réplication sur une instance de base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Pour cette raison, assurez-vous d’utiliser les commandes Amazon RDS [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source), et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour configurer la réplication entre votre base de données active et votre base de données Amazon RDS.
Pour définir le format de journalisation binaire pour une base de données MySQL ou MariaDB, mettez à jour le paramètre `binlog_format`. Si votre instance de base de données utilise le groupe de paramètres d’instance de base de données par défaut, créez un nouveau groupe de paramètres de base de données pour modifier le paramètre `binlog_format`. Dans MariaDB, MySQL 8.0 et versions antérieures, la valeur par défaut de `binlog_format` est `MIXED`. Cependant, vous pouvez également définir `binlog_format` sur `ROW` ou `STATEMENT` si vous avez besoin d’un format de journaux binaires (binlog) spécifique. Redémarrez votre instance de base de données pour que les modifications prennent effet. Dans MySQL 8.4 et versions ultérieures, la valeur par défaut de `binlog_format` est `ROW`.
Pour plus d’informations sur la configuration du paramètre `binlog_format`, consultez [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md). Pour plus d’informations sur les implications des différents types de réplication MySQL, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) de la documentation MySQL.
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Suivez ces instructions lorsque vous configurez une instance source externe et un réplica sur Amazon RDS :
+ Surveillez les événements de basculement de l'instance de base de données Amazon RDS qui constitue votre réplica. En cas de basculement, l'instance de base de données qui est votre réplica peut alors être recréée sur un nouvel hôte avec une autre adresse réseau. Pour plus d'informations sur la surveillance des événements de basculement, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Tenez à jour les journaux binaires sur votre instance source jusqu’à ce que vous ayez vérifié qu’ils ont été appliqués au réplica. Cette maintenance garantit que vous pouvez restaurer votre instance source en cas de défaillance.
+ Activez les sauvegardes automatiques sur votre instance de base de données Amazon RDS. L'activation des sauvegardes automatiques garantit que vous pouvez restaurer votre réplica sur un instant donné si vous devez resynchroniser votre instance source et votre réplica. Pour plus d'informations sur les sauvegardes et les point-in-time restaurations, consultez[Sauvegarde, restauration et exportation de données](CHAP_CommonTasks.BackupRestore.md).
**Pour configurer une réplication de position de fichier journal binaire avec une instance source externe**
1. Rendez l'instance MySQL ou MariaDB source accessible en lecture seule.
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Exécutez la commande `SHOW MASTER STATUS` sur l'instance source MySQL ou MariaDB pour déterminer l'emplacement du journal binaire.
Vous obtenez une sortie similaire à ce qui suit.
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Copiez la base de données de l'instance externe vers l'instance de base de données Amazon RDS à l'aide de `mysqldump`. Pour les bases de données très volumineuses, il se peut que vous vouliez utiliser la procédure décrite dans [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md).
Pour Linux, macOS ou Unix :
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Pour Windows :
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Note**
Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi.
Pour spécifier le nom d’hôte, le nom d’utilisateur, le port et le mot de passe afin de vous connecter à votre instance de base de données Amazon RDS, utilisez les options `--host`, `--user (-u)`, `--port` et `-p` dans la commande `mysql`. Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS : par exemple `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans la AWS Management Console au niveau des détails de l’instance.
1. Rendez l'instance source MySQL ou MariaDB à nouveau accessible en écriture.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Pour plus d’informations sur la création de sauvegardes en vue de les utiliser avec la réplication, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html).
1. Dans le AWS Management Console, ajoutez l'adresse IP du serveur qui héberge la base de données externe au groupe de sécurité du cloud privé virtuel (VPC) pour l'instance de base de données Amazon RDS. Pour plus d’informations sur la modification d’un groupe de sécurité de VPC, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
L'adresse IP peut changer lorsque les conditions suivantes sont réunies :
+ Vous utilisez une adresse IP publique pour la communication entre l'instance source externe et l'instance de base de données.
+ L'instance source externe a été arrêtée et redémarrée.
Si ces conditions sont réunies, vérifiez l'adresse IP avant de l'ajouter.
Vous devrez peut-être aussi configurer votre réseau local pour autoriser les connexions à partir de l'adresse IP de votre instance de base de données Amazon RDS. Cela permet la communication entre votre réseau local et votre instance MySQL ou MariaDB externe. Pour obtenir l'adresse IP de l'instance de base de données Amazon RDS, utilisez la commande `host`.
```
host db_instance_endpoint
```
Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS.
1. En utilisant le client de votre choix, connectez-vous à l’instance externe et créez un utilisateur à utiliser pour la réplication. Utilisez ce compte exclusivement pour la réplication et limitez-le à votre domaine pour améliorer la sécurité. Voici un exemple.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Pour l’instance externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l'utilisateur « `repl_user` » de votre domaine, émettez la commande suivante.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
1. Transformez l'instance de base de données Amazon RDS en réplica. Pour cela, connectez-vous d’abord à l’instance de base de données Amazon RDS en tant qu’utilisateur principal. Identifiez ensuite la base de données MySQL ou MariaDB externe comme instance source à l’aide de la commande [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) ou [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master). Utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 2. Les commandes suivantes sont des exemples.
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB et MySQL 8.0 et 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Sur RDS for MySQL, vous pouvez décider d’utiliser la réplication différée en exécutant à la place la procédure stockée [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) ou [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay). Sur RDS for MySQL, une des raisons d’utiliser la réplication différée est d’activer la reprise après sinistre avec la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Actuellement, RDS for MariaDB prend en charge la réplication différée, mais ne prend pas en charge la procédure `mysql.rds_start_replication_until`.
1. Sur l’instance de base de données Amazon RDS, émettez la commande [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication.
```
CALL mysql.rds_start_replication;
```
# Configuration multi-source-replication pour Amazon RDS for MySQL
La réplication multisource vous permet de configurer une instance de base de données Amazon RDS for MySQL en tant que réplique qui reçoit les événements du journal binaire de plusieurs instances de base de données sources RDS for MySQL. La réplication multisource est prise en charge pour les instances de base de données RDS for MySQL qui exécutent les versions de moteur suivantes :
+ Toutes les versions 8.4 de MySQL
+ 8.0.35 et versions mineures ultérieures
+ 5.7.44 et versions mineures ultérieures
Pour plus d’informations sur la réplication multisource MySQL, consultez [Réplication multisource MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) dans la documentation MySQL. La documentation MySQL contient des informations détaillées sur cette fonctionnalité. Cette rubrique décrit quant à elle comment configurer et gérer les canaux de réplication multisource sur vos instances de base de données RDS for MySQL.
## Cas d’utilisation de la réplication multisource
Les cas suivants sont idéaux pour l’utilisation de la réplication multisource sur RDS for MySQL :
+ Applications qui doivent fusionner ou combiner plusieurs partitions sur des instances de base de données distinctes en une seule partition.
+ Applications qui doivent générer des rapports à partir de données consolidées provenant de plusieurs sources.
+ Exigences relatives à la création de sauvegardes consolidées à long terme des données distribuées entre plusieurs instances de base de données RDS for MySQL.
## Conditions préalables pour la réplication multisource
Avant de configurer une réplication multisource, remplissez les conditions préalables suivantes.
+ Assurez-vous que les sauvegardes automatiques sont activées pour chaque instance de base de données source RDS for MySQL. L’activation des sauvegardes automatiques active la journalisation binaire. Pour découvrir comment activer des sauvegardes automatiques, consultez [Activation des sauvegardes automatiques](USER_WorkingWithAutomatedBackups.Enabling.md).
+ Pour éviter les erreurs de réplication, nous vous recommandons de bloquer les opérations d’écriture sur les instances de base de données sources. Pour cela, vous pouvez définir le paramètre `read-only` sur `ON` dans un groupe de paramètres personnalisé attaché à l’instance de base de données source RDS for MySQL. Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer un nouveau groupe de paramètres personnalisés ou pour modifier un groupe existant. Pour plus d’informations, consultez [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md) et [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
+ Pour chaque instance de base de données source, ajoutez l’adresse IP de l’instance au groupe de sécurité du cloud privé virtuel (VPC) Amazon pour l’instance de base de données multisource. Pour identifier l’adresse IP d’une instance de base de données source, vous pouvez exécuter la commande `dig RDS Endpoint`. Exécutez la commande à partir d’une instance Amazon EC2 dans le même VPC que l’instance de base de données multisource de destination.
+ Pour chaque instance de base de données source, utilisez un client pour vous y connecter et créez un utilisateur de base de données doté des privilèges requis pour la réplication, comme dans l’exemple suivant.
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user';
```
**Note**
À partir de MySQL 8.4, le privilège `REPLICATION SLAVE` est devenu obsolète et a été remplacé par `REPLICATION REPLICA`. Pour MySQL 8.4 et versions ultérieures, utilisez plutôt la syntaxe suivante :
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user';
```
## Configuration de canaux de réplication multisource sur les instances de base de données RDS for MySQL
La configuration des canaux de réplication multisource est similaire à la configuration de la réplication à source unique. Pour la réplication multisource, vous devez d’abord activer la journalisation binaire sur l’instance source. Vous importez ensuite les données des sources vers la réplique multisource. Ensuite, vous lancez la réplication à partir de chaque source en utilisant les coordonnées des journaux binaires ou en utilisant le positionnement automatique GTID.
Pour configurer une instance de base de données RDS for MySQL en tant que réplique multisource d’au moins deux instances de base de données RDS for MySQL, suivez les étapes ci-dessous.
**Topics**
+ [
### Étape 1 : Importer les données des instances de base de données source vers la réplique multisource
](#mysql-multi-source-replication-import)
+ [
### Étape 2 : Démarrer la réplication à partir des instances de base de données source vers la réplique multisource
](#mysql-multi-source-replication-setting-up-start-replication-other)
### Étape 1 : Importer les données des instances de base de données source vers la réplique multisource
Procédez comme suit sur chaque instance de base de données source.
Avant d’importer les données d’une source vers la réplique multisource, déterminez le fichier journal binaire actuel et sa position en exécutant la commande `SHOW MASTER STATUS`. Vous devez prendre note de ces informations pour les utiliser lors de l’étape suivante. Dans cet exemple de sortie, le fichier est `mysql-bin-changelog.000031` et la position est `107`.
**Note**
À partir de MySQL 8.4, la commande `SHOW MASTER STATUS` est devenue obsolète et a été remplacée par `SHOW BINARY LOG STATUS`. Pour MySQL 8.4 et versions ultérieures, utilisez plutôt `SHOW BINARY LOG STATUS`.
```
File Position
-----------------------------------
mysql-bin-changelog.000031 107
-----------------------------------
```
Copiez maintenant la base de données de l’instance de base de données source vers la réplique multisource en utilisant `mysqldump`, comme dans l’exemple suivant.
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u RDS_user_name \
-p RDS_password \
--host=RDS Endpoint | mysql \
--host=RDS Endpoint \
--port=3306 \
-u RDS_user_name \
-p RDS_password
```
Après avoir copié la base de données, vous pouvez définir le paramètre en lecture seule sur `OFF` sur l’instance de base de données source.
### Étape 2 : Démarrer la réplication à partir des instances de base de données source vers la réplique multisource
Pour chaque instance de base de données source, utilisez les informations d’identification de l’utilisateur administratif pour vous connecter à l’instance et exécutez les deux procédures stockées suivantes. Ces procédures stockées configurent la réplication sur un canal et démarrent la réplication. Cet exemple utilise le nom et la position du fichier binlog à partir de l’exemple de sortie de l’étape précédente.
```
CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1');
CALL mysql.rds_start_replication_for_channel('channel_1');
```
Pour plus d’informations sur l’utilisation de ces procédures stockées et d’autres afin de configurer et de gérer vos canaux de réplication, consultez [Gestion de la réplication multisource](mysql-stored-proc-multi-source-replication.md).
## Utilisation de filtres avec la réplication multisource
Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une réplique multisource. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les en exclure. Pour plus d’informations sur les filtres de réplication, consultez [Configuration des filtres de réplication avec MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md).
Avec la réplication multisource, vous pouvez configurer les filtres de réplication globalement ou au niveau du canal. Le filtrage au niveau du canal n’est disponible qu’avec les instances de base de données prises en charge exécutant la version 8.0 ou 8.4. Les exemples suivants montrent comment configurer des filtres globalement ou au niveau du canal.
Notez les exigences et le comportement suivants concernant le filtrage dans la réplication multisource :
+ Les noms des canaux doivent être placés entre guillemets (``).
+ Si vous modifiez les filtres de réplication dans le groupe de paramètres, le `sql_thread` des répliques multisource de tous les canaux mis à jour est redémarré de manière à appliquer les modifications de manière dynamique. Si une mise à jour implique un filtre global, tous les canaux de réplication en cours d’exécution sont redémarrés.
+ Tous les filtres globaux sont appliqués avant les filtres spécifiques au canal.
+ Si un filtre est appliqué globalement et au niveau du canal, seul celui au niveau du canal est appliqué. Par exemple, si les filtres sont `replicate_ignore_db="db1,`channel_22`:db2"`, `replicate_ignore_db` défini sur `db1` est appliqué à tous les canaux sauf `channel_22`, et seul `channel_22` ignore les modifications de `db2`.
Exemple 1 : Définition d’un filtre global
Dans l’exemple suivant, la base de données `temp_data` est exclue de la réplication sur tous les canaux.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate"
```
Exemple 2 : Définition d’un filtre au niveau du canal
Dans l’exemple suivant, les modifications apportées à la base de données `sample22` ne sont incluses que dans le canal `channel_22`. De même, les modifications apportées à la base de données `sample99` ne sont incluses que dans le canal `channel_99`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate"
```
## Surveillance des canaux de réplication multisource
Vous pouvez surveiller des canaux individuels dans une réplique multisource en utilisant les méthodes suivantes :
+ Pour surveiller l’état de tous les canaux ou d’un canal spécifique, connectez-vous à la réplique multisource et exécutez la commande `SHOW REPLICA STATUS` ou `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'`. Pour plus d’informations, consultez [Vérification du statut de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) dans la documentation MySQL.
+ Pour recevoir une notification lorsqu’un canal de réplication est démarré, arrêté ou supprimé, utilisez la notification d’événement RDS. Pour plus d’informations, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Pour surveiller le décalage d’un canal spécifique, vérifiez la métrique `ReplicationChannelLag` correspondante. Les points de données pour cette métrique, d’une durée de 60 secondes (1 minute), sont disponibles pendant 15 jours. Pour déterminer le décalage d’un canal de réplication, utilisez l’identifiant de l’instance et le nom du canal de réplication. Pour recevoir une notification lorsque ce décalage dépasse un certain seuil, vous pouvez configurer une CloudWatch alarme. Pour de plus amples informations, veuillez consulter [Surveillance des métriques Amazon RDS () avec Amazon CloudWatch](monitoring-cloudwatch.md).
## Considérations et pratiques exemplaires pour la réplication multisource
Avant d’utiliser la réplication multisource sur RDS for MySQL, passez en revue les considérations et les pratiques exemplaires suivantes :
+ Assurez-vous qu’une instance de base de données configurée en tant que réplique multisource dispose de ressources suffisantes telles que le débit, la mémoire, le processeur et les IOPS pour gérer la charge de travail provenant de plusieurs instances sources.
+ Surveillez régulièrement l’utilisation des ressources sur votre réplique multisource et ajustez la configuration du stockage ou de l’instance pour gérer la charge de travail sans surcharger les ressources.
+ Vous pouvez configurer la réplication multithread sur une réplique multisource en définissant la variable système `replica_parallel_workers` sur une valeur supérieure à `0`. Dans ce cas, le nombre de threads alloués à chaque canal est la valeur de cette variable, plus un thread coordinateur pour gérer les threads applicateurs.
+ Configurez correctement les filtres de réplication pour éviter les conflits. Pour répliquer une base de données complète vers une autre base de données sur une réplique, vous pouvez utiliser l’option `--replicate-rewrite-db`. Par exemple, vous pouvez répliquer toutes les tables de la base de données A vers la base de données B sur une instance de réplication. Cette approche peut être utile lorsque toutes les instances sources utilisent la même convention de dénomination de schéma. Pour plus d’informations sur l’option `--replicate-rewrite-db`, consultez [Options et variables de serveur de réplique](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) dans la documentation MySQL.
+ Pour éviter les erreurs de réplication, évitez d’écrire sur la réplique. Nous vous recommandons d’activer le paramètre `read_only` sur les répliques multisource pour bloquer les opérations d’écriture. Cela permet d’éliminer les problèmes de réplication causés par des opérations d’écriture contradictoires.
+ Pour améliorer les performances des opérations de lecture telles que les tris et les jointures à charge élevée exécutées sur la réplique multisource, pensez à utiliser RDS Optimized Reads. Cette fonctionnalité peut être utile pour les requêtes qui dépendent de grandes tables temporaires ou de fichiers de tri. Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour RDS for MySQL avec Lectures optimisées pour Amazon RDS](rds-optimized-reads.md).
+ Pour minimiser le délai de réplication et améliorer les performances d’une réplique multisource, pensez à activer les écritures optimisées. Pour de plus amples informations, veuillez consulter [Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL](rds-optimized-writes.md).
+ Effectuez des opérations de gestion (telles que la modification de la configuration) sur un canal à la fois et évitez de modifier plusieurs canaux à partir de plusieurs connexions. Ces pratiques peuvent entraîner des conflits dans les opérations de réplication. Par exemple, l’exécution simultanée de procédures `rds_skip_repl_error_for_channel` et `rds_start_replication_for_channel` à partir de plusieurs connexions peut entraîner l’omission d’événements sur un canal différent de celui prévu.
+ Vous pouvez activer les sauvegardes sur une instance de réplication multisource et exporter les données de cette instance vers un compartiment Amazon S3 afin de les stocker à long terme. Cependant, il est également important de configurer les sauvegardes avec une rétention appropriée sur les instances sources individuelles. Pour plus d’informations sur l’exportation de données d’instantanés vers Amazon S3, consultez [Exportation de données d’instantanés de bases de données vers Amazon S3 pour Amazon RDS](USER_ExportSnapshot.md).
+ Pour répartir la charge de travail de lecture sur une réplique multisource, vous pouvez créer des répliques de lecture à partir d’une réplique multisource. Vous pouvez localiser ces répliques de lecture de différentes manières en Régions AWS fonction des exigences de votre application. Pour plus d’informations sur les réplicas en lecture, consultez [Utilisation de réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.md).
## Limitations de la réplication multisource sur RDS for MySQL
Les limitations suivantes s’appliquent à la réplication multisource pour RDS for MySQL :
+ Actuellement, RDS for MySQL prend en charge la configuration d’un maximum de 15 canaux pour une réplique multisource.
+ Une instance de réplication en lecture ne peut pas être configurée en tant que réplique multisource.
+ Le schéma de performance doit être activé sur l’instance de réplique pour que vous puissiez configurer la réplication multisource sur RDS for MySQL exécutant le moteur version 5.7. L’activation du schéma de performance est facultative sur RDS for MySQL exécutant le moteur version 8.0 ou 8.4.
+ Pour RDS for MySQL exécutant le moteur version 5.7, les filtres de réplication s’appliquent à tous les canaux de réplication. Pour RDS for MySQL exécutant le moteur version 8.0 ou 8.4, vous pouvez configurer des filtres qui s’appliquent à tous les canaux de réplication ou à des canaux individuels.
+ La restauration d'un instantané RDS ou l'exécution d'un Point-in-time-Restore (PITR) ne restaurent pas les configurations de canaux de réplication multi-sources.
+ Lorsque vous créez une réplique en lecture d’une réplique multisource, elle ne réplique que les données de l’instance multisource. Elle ne restaure pas la configuration d’un canal.
+ MySQL ne prend pas en charge la configuration d’un nombre différent de travailleurs parallèles pour chaque canal. Chaque canal reçoit le même nombre de travailleurs parallèles en fonction de la valeur `replica_parallel_workers`.
Les limitations supplémentaires suivantes s’appliquent si votre cible de réplication multisource est un cluster de bases de données Multi-AZ :
+ Un canal doit être configuré pour une instance source RDS for MySQL avant toute écriture sur cette instance.
+ La réplication basée sur GTID doit être activée sur chaque instance source RDS for MySQL.
+ Un événement de basculement sur le cluster de bases de données supprime la configuration de réplication multisource. Pour restaurer cette configuration, il est nécessaire de répéter les étapes de configuration.
# Configuration de clusters actifs-actifs pour RDS for MySQL
Un cluster actif-actif dans Amazon RDS est une configuration de base de données dans laquelle plusieurs nœuds gèrent activement les opérations de lecture et d’écriture, répartissant la charge de travail entre les instances afin d’améliorer la disponibilité et la capacité de mise à l’échelle. Chaque nœud du cluster est synchronisé pour maintenir la cohérence des données, ce qui permet une haute disponibilité et un basculement plus rapide en cas de défaillance du nœud.
Vous pouvez configurer un cluster actif-actif pour RDS for MySQL à l’aide du plugin MySQL Group Replication. Le plugin de réplication de groupe est pris en charge pour les instances de base de données RDS for MySQL qui exécutent les versions suivantes :
+ Toutes les versions 8.4 de MySQL
+ MySQL 8.0.35 et versions mineures ultérieures
Pour en savoir plus sur la réplication de groupe MySQL, consultez [Réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) dans la documentation MySQL. La documentation MySQL contient des informations détaillées sur cette fonctionnalité. Cette rubrique décrit quant à elle comment configurer et gérer le plugin sur vos instances de base de données RDS for MySQL.
**Note**
Par souci de concision, toutes les mentions de cluster « actif-actif » dans cette rubrique font référence aux clusters actifs-actifs utilisant le plugin de réplication de groupe MySQL.
## Cas d’utilisation pour les clusters actifs-actifs
Les cas suivants sont de bons candidats pour l’utilisation de clusters actifs-actifs :
+ Applications qui ont besoin de toutes les instances de base de données du cluster pour prendre en charge les opérations d’écriture. Le plugin Réplication de groupe assure la cohérence des données sur chaque instance de base de données du cluster actif-actif. Pour en savoir plus sur son fonctionnement, consultez [Réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) dans la documentation MySQL.
+ Applications nécessitant une disponibilité continue de la base de données. Dans le cas d’un cluster actif-actif, les données sont conservées sur toutes les instances de base de données du cluster. En cas de défaillance d’une instance de base de données, l’application peut rediriger le trafic vers une autre instance de base de données du cluster.
+ Applications susceptibles de devoir répartir les opérations de lecture et d’écriture entre les différentes instances de base de données du cluster à des fins d’équilibrage de charge. Avec un cluster actif-actif, vos applications peuvent envoyer du trafic de lecture vers des instances de base de données spécifiques et du trafic d’écriture vers d’autres instances. Vous pouvez également changer à tout moment les instances de base de données auxquelles envoyer des lectures ou des écritures.
**Topics**
+ [
## Cas d’utilisation pour les clusters actifs-actifs
](#mysql-active-active-clusters-benefits)
+ [
# Limites et considérations relatives aux clusters actifs-actifs
](mysql-active-active-clusters-considerations-limitations.md)
+ [
# Préparation à un cluster actif-actif inter-VPC
](mysql-active-active-clusters-cross-vpc-prerequisites.md)
+ [
# Réglages de paramètres requis pour les clusters actifs-actifs
](mysql-active-active-clusters-parameters.md)
+ [
# Conversion d’une instance de base de données existante en cluster actif-actif
](mysql-active-active-clusters-converting.md)
+ [
# Configuration d’un cluster actif-actif avec de nouvelles instances de base de données
](mysql-active-active-clusters-setting-up.md)
+ [
# Ajout d’une instance de base de données à un cluster actif-actif
](mysql-active-active-clusters-adding.md)
+ [
# Surveillance des clusters actifs-actifs
](mysql-active-active-clusters-monitoring.md)
+ [
# Arrêt de la réplication de groupe sur une instance de base de données dans un cluster actif-actif
](mysql-active-active-clusters-stopping.md)
+ [
# Modification du nom d’une instance de base de données dans un cluster actif-actif
](mysql-active-active-clusters-renaming.md)
+ [
# Suppression d’une instance de base de données d’un cluster actif-actif
](mysql-active-active-clusters-remove.md)
# Limites et considérations relatives aux clusters actifs-actifs
Les clusters actifs-actifs d’Amazon RDS améliorent la disponibilité et la capacité de mise à l’échelle en répartissant les charges de travail sur plusieurs instances. Cependant, il existe des limites et des considérations importantes à prendre en compte lors de l’utilisation de cette architecture.
Les sections suivantes décrivent les facteurs clés tels que les délais de réplication, la résolution des conflits, l’allocation des ressources et le comportement de basculement. La compréhension de ces considérations peut contribuer à garantir des performances et une fiabilité optimales dans les déploiements de clusters actifs-actifs.
**Topics**
+ [
## Limites applicables aux clusters actifs-actifs RDS for MySQL
](#mysql-active-active-clusters-limitations)
+ [
## Considérations et bonnes pratiques relatives aux clusters actifs-actifs RDS for MySQL
](#mysql-active-active-clusters-considerations)
## Limites applicables aux clusters actifs-actifs RDS for MySQL
Les limites suivantes s’appliquent aux clusters actifs-actifs pour RDS for MySQL :
+ Le nom d’utilisateur principal ne peut pas être `rdsgrprepladmin` pour les instances de base de données d’un cluster actif-actif. Ce nom d’utilisateur est réservé aux connexions de réplication de groupe.
+ Pour les instances de base de données avec des réplicas en lecture dans des clusters actifs-actifs, un état de réplication prolongé autre que `Replicating` peut entraîner le dépassement des limites de stockage des fichiers journaux. Pour en savoir plus sur le statut des réplicas en lecture, consultez [Supervision de la réplication en lecture](USER_ReadRepl.Monitoring.md).
+ Les déploiements bleu/vert ne sont pas pris en charge pour les instances de base de données au sein d’un cluster actif-actif. Pour plus d’informations, consultez [Utilisation d'Amazon RDS ( Blue/Green Deployments) pour les mises à jour de bases de données](blue-green-deployments.md).
+ L’authentification Kerberos n’est pas prise en charge pour les instances de base de données d’un cluster actif-actif. Pour de plus amples informations, veuillez consulter [Utilisation de l’authentification Kerberos pour Amazon RDS for MySQL](mysql-kerberos.md).
+ Les instances de base de données d’un cluster de bases de données multi-AZ ne peuvent pas être ajoutées à un cluster actif-actif. Toutefois, les instances de base de données d’un déploiement d’instance de base de données multi-AZ peuvent être ajoutées à un cluster actif-actif. Pour de plus amples informations, veuillez consulter [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
+ Les tables dépourvues de clé primaire ne sont pas répliquées dans un cluster actif-actif, car les écritures sont rejetées par le plug-in Réplication de groupe.
+ Les tables non-InnoDB ne sont pas répliquées dans un cluster actif-actif.
+ Les clusters actifs-actifs ne prennent pas en charge les instructions DML et DDL simultanées sur les différentes instances de base de données du cluster.
+ Vous ne pouvez pas configurer un cluster actif-actif afin d’utiliser le mode primaire unique pour le mode de réplication du groupe. Pour cette configuration, nous vous recommandons d’utiliser plutôt un cluster de bases de données multi-AZ. Pour de plus amples informations, veuillez consulter [Déploiements de cluster de bases de données multi-AZ pour Amazon RDS](multi-az-db-clusters-concepts.md).
+ La réplication multisource n’est pas prise en charge pour les instances de base de données d’un cluster actif-actif.
+ Un cluster actif-actif entre régions ne peut pas appliquer la vérification de l’autorité de certification (CA) pour les connexions de réplication de groupe.
## Considérations et bonnes pratiques relatives aux clusters actifs-actifs RDS for MySQL
Avant d’utiliser les clusters actifs-actifs RDS for MySQL, passez en revue les considérations et les bonnes pratiques suivantes :
+ Les clusters actifs-actifs ne peuvent pas contenir plus de neuf instances de base de données.
+ Avec le plug-in Réplication de groupe, vous pouvez contrôler les garanties de cohérence des transactions du cluster actif-actif. Pour plus d’informations, consultez [Garanties de cohérence des transactions](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) dans la documentation MySQL.
+ Des conflits sont possibles lorsque différentes instances de base de données mettent à jour la même ligne dans un cluster actif-actif. Pour en savoir plus sur les conflits et leur résolution, consultez [Réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) dans la documentation MySQL.
+ Pour la tolérance aux pannes, ajoutez au moins trois instances de base de données dans votre cluster actif-actif. Il est possible de configurer un cluster actif-actif avec une ou deux instances de base de données uniquement, mais le cluster ne tolérera pas les pannes. Pour en savoir plus sur la tolérance aux pannes, consultez [Tolérance aux pannes](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) dans la documentation MySQL.
+ Lorsqu’une instance de base de données rejoint un cluster actif-actif existant et exécute la même version de moteur que la version la plus basse du cluster, l’instance de base de données le rejoint en mode lecture-écriture.
+ Lorsqu’une instance de base de données rejoint un cluster actif-actif existant et exécute une version de moteur supérieure à la version la plus basse du cluster, l’instance de base de données doit rester en mode lecture seule.
+ Si vous activez la réplication de groupe pour une instance de base de données en définissant son `rds.group_replication_enabled` paramètre sur `1` dans le groupe de paramètres de base de données, mais que la réplication n'a pas démarré ou n'a pas pu démarrer, l'instance de base de données est placée en super-read-only mode pour éviter les incohérences dans les données. Pour plus d'informations sur super-read-only le mode, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only).
+ Vous pouvez mettre à niveau une instance de base de données dans un cluster actif-actif, mais elle est en lecture seule jusqu’à ce que toutes les autres instances de base de données du cluster actif-actif soient mises à niveau vers une version du moteur identique ou supérieure. Lorsque vous mettez à niveau une instance de base de données, celle-ci rejoint automatiquement le même cluster actif-actif une fois la mise à niveau terminée. Afin d’éviter un passage involontaire en mode lecture seule pour une instance de base de données, désactivez les mises à niveau automatiques des versions mineures pour celle-ci. Pour en savoir plus sur la mise à niveau d’une instance de base de données MySQL, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
+ Vous pouvez ajouter une instance de base de données dans un déploiement d’instance de base de données multi-AZ à un cluster actif-actif existant. Vous pouvez également convertir une instance de base de données mono-AZ d’un cluster actif-actif en déploiement d’instance de base de données multi-AZ. Si une instance de base de données principale échoue dans un déploiement multi-AZ, cette instance principale bascule vers l’instance de secours. La nouvelle instance de base de données principale rejoint automatiquement le même cluster une fois le basculement terminé. Pour plus d’informations sur les déploiements d’instance de base de données multi-AZ, consultez [Déploiements de l’instance de base de données multi-AZ pour Amazon RDS](Concepts.MultiAZSingleStandby.md).
+ Nous recommandons des plages de temps différentes pour les fenêtres de maintenance des instances de base de données d’un cluster actif-actif. Cette pratique évite la mise hors ligne simultanée de plusieurs instances de base de données du cluster pour des raisons de maintenance. Pour de plus amples informations, veuillez consulter [Fenêtre de maintenance Amazon RDS](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance).
+ Les clusters actifs-actifs peuvent utiliser SSL pour les connexions entre les instances de base de données. Pour configurer les connexions SSL, définissez les paramètres [ group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) et [group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode). Les valeurs de ces paramètres doivent correspondre à toutes les instances de base de données du cluster actif-actif.
Actuellement, les clusters actifs-actifs ne prennent pas en charge la vérification par l’autorité de certification (CA) pour les connexions entre des Régions AWS. Le paramètre [group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) doit donc être défini sur `DISABLED` (valeur par défaut) ou sur `REQUIRED` pour les clusters entre régions.
+ Un cluster actif-actif RDS for MySQL s’exécute en mode multi-primaire. La valeur par défaut de [group\$1replication\$1enforce\$1update\$1everywhere\$1checks](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) est `ON` et le paramètre est statique. Lorsque ce paramètre est défini sur `ON`, les applications ne peuvent pas l’insérer dans une table soumise à des contraintes de clé étrangère en cascade.
+ Un cluster actif-actif RDS for MySQL utilise la pile de communication MySQL pour la sécurité des connexions au lieu de XCOM. Pour plus d’informations, consultez [Pile de communication pour la gestion de la sécurité des connexions](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) dans la documentation MySQL.
+ Lorsqu’un groupe de paramètres de base de données est associé à une instance de base de données dans un cluster actif-actif, nous recommandons de n’associer ce groupe qu’aux autres instances de base de données présentes dans le cluster.
+ Les clusters actifs-actifs prennent en charge uniquement les instances de base de données RDS for MySQL. Ces instances de base de données doivent exécuter des versions prises en charge du moteur de base de données.
+ Lorsqu’une instance de base de données d’un cluster actif-actif subit une défaillance inattendue, RDS démarre automatiquement la récupération de l’instance de base de données. Si l'instance de base de données ne se rétablit pas, nous vous recommandons de la remplacer par une nouvelle instance de base de données en effectuant une point-in-time restauration avec une instance de base de données saine dans le cluster. Pour obtenir des instructions, veuillez consulter [Ajout d’une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr).
+ Vous pouvez supprimer une instance de base de données d’un cluster actif-actif sans affecter les autres instances de base de données du cluster. Pour en savoir plus sur la suppression d’une instance de base de données, consultez [Suppression d'une instance DB](USER_DeleteInstance.md).
+ Lorsqu’une instance de base de données quitte involontairement un cluster actif-actif, le paramètre `group_replication_exit_state_action` passe par défaut à `OFFLINE_MODE`. Dans cet état, l’instance de base de données est inaccessible et vous devez la redémarrer pour qu’elle se remette en ligne et rejoigne le cluster. Vous pouvez changer ce comportement en modifiant le paramètre `group_replication_exit_state_action` dans un groupe de paramètres personnalisés. En définissant le paramètre sur `READ_ONLY`, lorsque l’instance de base de données quitte involontairement un cluster, elle passe en mode super lecture seule au lieu d’être mise hors ligne.
# Préparation à un cluster actif-actif inter-VPC
Vous pouvez configurer un cluster actif-actif avec des instances de base de données Amazon RDS for MySQL dans plusieurs VPC. Ils VPCs peuvent être identiques Région AWS ou différents Régions AWS.
**Note**
L'envoi de trafic entre plusieurs Régions AWS sites peut entraîner des coûts supplémentaires. Pour plus d’informations, consultez [Présentation des coûts de transfert de données pour les architectures communes](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/).
Si vous configurez un cluster actif-actif dans un VPC unique, vous pouvez ignorer ces étapes et passer à [Configuration d’un cluster actif-actif avec de nouvelles instances de base de données](mysql-active-active-clusters-setting-up.md).
**Pour préparer un cluster actif-actif avec des instances de base de données dans plusieurs VPC**
1. Assurez-vous que les plages d' IPv4 adresses des blocs CIDR répondent aux exigences suivantes :
+ Les plages d' IPv4 adresses dans les blocs CIDR du VPCs Can't Overlap.
+ Toutes les plages d' IPv4 adresses des blocs CIDR doivent être inférieures `128.0.0.0/subnet_mask` ou supérieures à *subnet\$1mask* 128.0.0.0/.
Les plages suivantes illustrent ces exigences :
+ `10.1.0.0/16` dans un VPC et `10.2.0.0/16` dans l’autre VPC est pris en charge.
+ `172.1.0.0/16` dans un VPC et `172.2.0.0/16` dans l’autre VPC est pris en charge.
+ `10.1.0.0/16` dans un VPC et `10.1.0.0/16` dans l’autre VPC *n’est pas* pris en charge, car les plages se chevauchent.
+ `10.1.0.0/16` dans un VPC et `172.1.0.0/16` dans l’autre VPC *n’est pas* pris en charge, car l’un est inférieur à `128.0.0.0/subnet_mask` et l’autre est supérieur à `128.0.0.0/subnet_mask`.
Pour plus d’informations sur les blocs CIDR, consultez [Blocs CIDR VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) dans le *Guide de l’utilisateur Amazon VPC*.
1. Dans chaque VPC, vérifiez que la résolution DNS et les noms d’hôte DNS sont tous les deux activés.
Pour plus d’instructions, consultez [Afficher et mettre à jour les attributs DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dans le *Guide de l’utilisateur Amazon VPC*.
1. Configurez le VPCs afin de pouvoir acheminer le trafic entre eux de l'une des manières suivantes :
+ Créez une connexion d'appairage VPC entre. VPCs
Pour plus d’instructions, consultez [Créer une connexion d’appairage de VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) dans le *Guide d’appairage Amazon VPC*. Dans chaque VPC, assurez-vous que des règles entrantes pour vos groupes de sécurité font référence aux groupes de sécurité du VPC appairé. Cette étape autorise le trafic vers et depuis les instances associées au groupe de sécurité référencé dans le VPC appairé. Pour plus d’instructions, consultez [Mise à jour de vos groupes de sécurité pour référencer des groupes de sécurité pairs](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) dans le *Guide d’appairage Amazon VPC*.
+ Créez une passerelle de transit entre les VPCs.
Pour plus d’instructions, consultez [Mise en route avec les passerelles de transit](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) dans les *Passerelles de transit Amazon VPC*. Dans chaque VPC, assurez-vous qu’il existe des règles entrantes pour vos groupes de sécurité qui autorisent le trafic en provenance de l’autre VPC, telles que des règles entrantes qui spécifient le CIDR de l’autre VPC. Cette étape autorise le trafic vers et depuis les instances associées au groupe de sécurité référencé dans le cluster actif-actif. Pour plus d'informations, consultez la section [Contrôlez le trafic vers vos AWS ressources à l'aide de groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) dans le *guide de l'utilisateur Amazon VPC*.
# Réglages de paramètres requis pour les clusters actifs-actifs
La configuration des paramètres des clusters actifs-actifs dans Amazon RDS for MySQL est essentielle pour maintenir des performances constantes et une stabilité opérationnelle. Ce tableau détaille les principaux paramètres qui contrôlent la réplication, la résolution des conflits et la distribution de la charge de travail. Une configuration correcte garantit une synchronisation efficace entre les nœuds, minimise le délai de réplication et optimise l’utilisation des ressources dans les environnements distribués ou à trafic élevé.
| Paramètre | Description | Paramètre obligatoire |
| --- | --- | --- |
| `binlog_format` | Définit le format de journalisation binaire. La valeur par défaut pour RDS for MySQL versions 8.0 et antérieures est `MIXED`. La valeur par défaut pour RDS for MySQL versions 8.4 est `ROW`. Pour plus d’informations, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format). | `ROW` |
| `enforce_gtid_consistency` | Renforce la cohérence du GTID pour l’exécution des instructions. La valeur par défaut pour RDS for MySQL est `OFF`. Pour plus d’informations, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency). | `ON` |
| `group_replication_group_name` | Définit le nom de réplication de groupe sur un UUID. Le format UUID est `11111111-2222-3333-4444-555555555555`. Vous pouvez générer un UUID MySQL en vous connectant à une instance de base de données MySQL et en exécutant `SELECT UUID()`. La valeur doit être la même pour toutes les instances de base de données d’un cluster actif-actif. Pour plus d’informations, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid). | Un UUID MySQL |
| `gtid-mode` | Contrôle la journalisation basée sur GTID. La valeur par défaut pour RDS for MySQL est `OFF_PERMISSIVE`. Pour plus d’informations, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode). | `ON` |
| `rds.custom_dns_resolution` | Spécifie si vous souhaitez autoriser la résolution DNS depuis le serveur Amazon DNS dans votre VPC. La résolution DNS doit être activée lorsque la réplication de groupe est activée avec le paramètre `rds.group_replication_enabled`. La résolution DNS ne peut pas être activée lorsque la réplication de groupe est activée avec le paramètre `rds.group_replication_enabled`. Pour plus d’informations, consultez [Serveur Amazon DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) dans le *Guide de l’utilisateur Amazon VPC*. | `1` |
| `rds.group_replication_enabled` | Spécifie si la réplication de groupe est activée pour une instance de base de données. La réplication de groupe doit être activée sur une instance de base de données dans un cluster actif-actif. | `1` |
| `replica_preserve_commit_order` (RDS for MySQL 8.4 et versions ultérieures) ou `slave_preserve_commit_order` (RDS for MySQL versions 8.0) | Contrôle l’ordre dans lequel les transactions sont validées sur un réplica. La valeur par défaut pour RDS for MySQL est `ON`. Pour plus d’informations, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order). | `ON` |
# Conversion d’une instance de base de données existante en cluster actif-actif
La version du moteur de base de données de l’instance de base de données que vous souhaitez migrer vers un cluster actif-actif doit être l’une des versions suivantes :
+ Toutes les versions 8.4 de MySQL
+ MySQL 8.0.35 et versions mineures ultérieures
Si vous devez mettre à niveau la version du moteur, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
Si vous configurez un cluster actif-actif avec des instances de base de données dans plusieurs VPC, assurez-vous de remplir les conditions requises dans [Préparation à un cluster actif-actif inter-VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md).
Procédez comme suit pour migrer une instance de base de données existante vers un cluster actif-actif pour RDS for MySQL.
**Topics**
+ [
## Étape 1 : Définir les paramètres du cluster actif-actif dans un ou plusieurs groupes de paramètres personnalisés
](#mysql-active-active-clusters-converting-parameter-group)
+ [
## Étape 2 : Associer l’instance de base de données à un groupe de paramètres de base de données dont les paramètres de réplication de groupe requis sont définis
](#mysql-active-active-clusters-converting-associate-parameter-group)
+ [
## Étape 3 : Créer le cluster actif-actif
](#mysql-active-active-clusters-converting-associate-parameter-groups)
+ [
## Étape 4 : Créer des instances de base de données RDS for MySQL supplémentaires pour le cluster actif-actif
](#mysql-active-active-clusters-converting-add-db-instances)
+ [
## Étape 5 : Initialiser le groupe sur l’instance de base de données que vous convertissez
](#mysql-active-active-clusters-converting-start-replication-first)
+ [
## Étape 6 : Démarrer la réplication sur les autres instances de base de données du cluster actif-actif
](#mysql-active-active-clusters-converting-start-replication-other)
+ [
## Étape 7 : (Recommandé) Vérifiez l’état du cluster actif-actif
](#mysql-active-active-clusters-converting-view)
## Étape 1 : Définir les paramètres du cluster actif-actif dans un ou plusieurs groupes de paramètres personnalisés
Les instances de base de données RDS for MySQL d’un cluster actif-actif doivent être associées à un groupe de paramètres personnalisé dont les paramètres requis sont correctement définis. Pour en savoir plus sur les paramètres et le réglage requis pour chacun, consultez [Réglages de paramètres requis pour les clusters actifs-actifs](mysql-active-active-clusters-parameters.md).
Vous pouvez définir ces paramètres dans de nouveaux groupes de paramètres ou dans des groupes de paramètres existants. Toutefois, pour éviter d’affecter accidentellement les instances de base de données qui ne font pas partie du cluster actif-actif, nous vous recommandons vivement de créer un nouveau groupe de paramètres personnalisé. Les instances de base de données d’un cluster actif-actif peuvent être associées au même groupe de paramètres de base de données ou à différents groupes.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer un nouveau groupe de paramètres personnalisés. Pour de plus amples informations, veuillez consulter [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'exemple suivant exécute la [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI commande pour créer un groupe de paramètres de base de données personnalisé nommé `myactivepg` d'après RDS pour MySQL 8.0 :
Pour Linux, macOS ou Unix :
```
aws rds create-db-parameter-group \
--db-parameter-group-name myactivepg \
--db-parameter-group-family mysql8.0 \
--description "Parameter group for active-active clusters"
```
Pour Windows :
```
aws rds create-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--db-parameter-group-family mysql8.0 ^
--description "Parameter group for active-active clusters"
```
Vous pouvez également utiliser le AWS Management Console ou le AWS CLI pour définir les paramètres du groupe de paramètres personnalisés. Pour de plus amples informations, veuillez consulter [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
L'exemple suivant exécute la [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI commande pour définir les paramètres de RDS pour MySQL 8.0. Pour utiliser cet exemple avec RDS for MySQL 8.4, remplacez `slave_preserve_commit_order` par `replica_preserve_commit_order`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myactivepg \
--parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \
"ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \
"ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \
"ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \
"ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \
"ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \
"ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^
"ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^
"ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^
"ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^
"ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^
"ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^
"ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```
## Étape 2 : Associer l’instance de base de données à un groupe de paramètres de base de données dont les paramètres de réplication de groupe requis sont définis
Associez l’instance de base de données à un groupe de paramètres que vous avez créé ou modifié à l’étape précédente. Pour obtenir des instructions, consultez [Association d’un groupe de paramètres de base de données à une instance de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Associating.md).
Redémarrez l’instance de base de données pour que les nouveaux paramètres prennent effet. Pour obtenir des instructions, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
## Étape 3 : Créer le cluster actif-actif
Dans le groupe de paramètres de base de données associé à l’instance de base de données, définissez le paramètre `group_replication_group_seeds` sur le point de terminaison de l’instance de base de données que vous convertissez.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour définir le paramètre. Vous n’avez pas besoin de redémarrer l’instance de base de données après avoir défini ce paramètre. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
L'exemple suivant exécute la [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI commande pour définir les paramètres :
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myactivepg \
--parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```
## Étape 4 : Créer des instances de base de données RDS for MySQL supplémentaires pour le cluster actif-actif
Pour créer des instances de base de données supplémentaires pour le cluster actif-actif, effectuez une point-in-time restauration sur l'instance de base de données que vous convertissez. Pour obtenir des instructions, veuillez consulter [Ajout d’une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr).
Un cluster actif-actif peut inclure jusqu’à neuf instances de base de données. Effectuez la point-in-time restauration sur l'instance de base de données jusqu'à ce que vous disposiez du nombre d'instances de base de données que vous souhaitez pour le cluster. Lorsque vous effectuez cette point-in-recovery opération, assurez-vous d'associer l'instance de base de données que vous ajoutez à un groupe de paramètres de base de données `rds.group_replication_enabled` défini sur`1`. Sinon, la réplication de groupe ne démarrera pas sur l’instance de base de données ajoutée récemment.
## Étape 5 : Initialiser le groupe sur l’instance de base de données que vous convertissez
Initialisez le groupe et lancez la réplication :
1. Connectez-vous à l’instance de base de données que vous êtes en train de convertir dans un client SQL. Pour plus d’informations sur la connexion à une instance de base de données RDS for MySQL, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md).
1. Dans le client SQL, exécutez les procédures stockées suivantes et remplacez-les *group\$1replication\$1user\$1password* par le mot de passe de l'`rdsgrprepladmin`utilisateur. L’utilisateur `rdsgrprepladmin` est réservé aux connexions de réplication de groupe dans un cluster actif-actif. Le mot de passe de cet utilisateur doit être le même sur toutes les instances de base de données d’un cluster actif-actif.
```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(1);
```
Cet exemple définit la valeur `binlog retention hours` sur `168`, ce qui signifie que les fichiers journaux binaires sont retenus pendant sept jours sur l’instance de base de données. Vous pouvez ajuster cette valeur en fonction des exigences.
Cet exemple indique `1` dans la procédure stockée `mysql.rds_group_replication_start` d’initialiser un nouveau groupe avec l’instance de base de données actuelle.
Pour plus d’informations sur les procédures stockées appelées dans l’exemple, consultez [Gestion des clusters actifs-actifs](mysql-stored-proc-active-active-clusters.md).
## Étape 6 : Démarrer la réplication sur les autres instances de base de données du cluster actif-actif
Pour chacune des instances de base de données du cluster actif-actif, utilisez un client SQL pour vous connecter à l’instance et exécutez les procédures stockées suivantes. *group\$1replication\$1user\$1password*Remplacez-le par le mot de passe de l'`rdsgrprepladmin`utilisateur.
```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(0);
```
Cet exemple définit la valeur `binlog retention hours` sur `168`, ce qui signifie que les fichiers journaux binaires sont retenus pendant sept jours sur chaque instance de base de données. Vous pouvez ajuster cette valeur en fonction des exigences.
Cet exemple indique `0` dans la procédure stockée `mysql.rds_group_replication_start` pour associer l’instance de base de données actuelle à un groupe existant.
**Astuce**
Assurez-vous d’exécuter ces procédures stockées sur toutes les autres instances de base de données du cluster actif-actif.
## Étape 7 : (Recommandé) Vérifiez l’état du cluster actif-actif
Pour vous assurer que chaque membre du cluster est correctement configuré, vérifiez l’état du cluster en vous connectant à une instance de base de données du cluster actif-actif et en exécutant la commande SQL suivante :
```
SELECT * FROM performance_schema.replication_group_members;
```
Votre sortie doit afficher `ONLINE` pour le `MEMBER_STATE` de chaque instance de base de données, comme dans l’exemple de sortie suivant :
```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```
Pour plus d’informations sur les valeurs possibles de `MEMBER_STATE`, consultez [États de serveur de réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) dans la documentation MySQL.
# Configuration d’un cluster actif-actif avec de nouvelles instances de base de données
Procédez comme suit pour configurer un cluster actif-actif à l’aide de nouvelles instances de base de données Amazon RDS for MySQL.
Si vous configurez un cluster actif-actif avec des instances de base de données dans plusieurs VPC, assurez-vous de remplir les conditions requises dans [Préparation à un cluster actif-actif inter-VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md).
**Topics**
+ [
## Étape 1 : Définir les paramètres du cluster actif-actif dans un ou plusieurs groupes de paramètres personnalisés
](#mysql-active-active-clusters-setting-up-parameter-group)
+ [
## Étape 2 : Créer des instances de base de données RDS for MySQL pour le cluster actif-actif
](#mysql-active-active-clusters-setting-up-db-instances)
+ [
## Étape 3 : Spécifier les instances de base de données dans le cluster actif-actif
](#mysql-active-active-clusters-setting-up-associate-parameter-groups)
+ [
## Étape 4 : Initialiser le groupe sur une instance de base de données et démarrer la réplication
](#mysql-active-active-clusters-setting-up-start-replication-first)
+ [
## Étape 5 : Démarrer la réplication sur les autres instances de base de données du cluster actif-actif
](#mysql-active-active-clusters-setting-up-start-replication-other)
+ [
## Étape 6 : (Recommandé) Vérifiez l’état du cluster actif-actif
](#mysql-active-active-clusters-setting-up-view)
+ [
## Étape 7 : (Facultatif) Importer des données dans une instance de base de données du cluster actif-actif
](#mysql-active-active-clusters-import)
## Étape 1 : Définir les paramètres du cluster actif-actif dans un ou plusieurs groupes de paramètres personnalisés
Les instances de base de données RDS for MySQL d’un cluster actif-actif doivent être associées à un groupe de paramètres personnalisé dont les paramètres requis sont correctement définis. Pour en savoir plus sur les paramètres et le réglage requis pour chacun, consultez [Réglages de paramètres requis pour les clusters actifs-actifs](mysql-active-active-clusters-parameters.md).
Vous pouvez définir ces paramètres dans de nouveaux groupes de paramètres ou dans des groupes de paramètres existants. Toutefois, pour éviter d’affecter accidentellement les instances de base de données qui ne font pas partie du cluster actif-actif, nous vous recommandons vivement de créer un nouveau groupe de paramètres personnalisé. Les instances de base de données d’un cluster actif-actif peuvent être associées au même groupe de paramètres de base de données ou à différents groupes.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer un nouveau groupe de paramètres personnalisés. Pour de plus amples informations, veuillez consulter [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'exemple suivant exécute la [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI commande pour créer un groupe de paramètres de base de données personnalisé nommé `myactivepg` d'après RDS pour MySQL 8.0 :
Pour Linux, macOS ou Unix :
```
aws rds create-db-parameter-group \
--db-parameter-group-name myactivepg \
--db-parameter-group-family mysql8.0 \
--description "Parameter group for active-active clusters"
```
Pour Windows :
```
aws rds create-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--db-parameter-group-family mysql8.0 ^
--description "Parameter group for active-active clusters"
```
Vous pouvez également utiliser le AWS Management Console ou le AWS CLI pour définir les paramètres du groupe de paramètres personnalisés. Pour de plus amples informations, veuillez consulter [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
L'exemple suivant exécute la [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI commande pour définir les paramètres de RDS pour MySQL 8.0. Pour utiliser cet exemple avec RDS for MySQL 8.4, remplacez `slave_preserve_commit_order` par `replica_preserve_commit_order`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myactivepg \
--parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \
"ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \
"ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \
"ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \
"ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \
"ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \
"ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^
"ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^
"ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^
"ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^
"ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^
"ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^
"ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot"
```
## Étape 2 : Créer des instances de base de données RDS for MySQL pour le cluster actif-actif
Les clusters actifs-actifs sont pris en charge pour les versions suivantes des instances de base de données RDS for MySQL :
+ Toutes les versions 8.4 de MySQL
+ MySQL 8.0.35 et versions mineures ultérieures
Vous pouvez créer jusqu’à neuf nouvelles instances de bases de données pour le cluster.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer de nouvelles instances de base de données. Pour plus d’informations sur la création d’une instance de base de données, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md). Lorsque vous créez l’instance de base de données, associez-la à un groupe de paramètres de base de données que vous avez créé ou modifié à l’étape précédente.
## Étape 3 : Spécifier les instances de base de données dans le cluster actif-actif
Dans le groupe de paramètres de base de données associé à chaque instance de base de données, définissez le paramètre `group_replication_group_seeds` sur les points de terminaison des instances de base de données que vous souhaitez inclure dans le cluster.
Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour définir le paramètre. Vous n’avez pas besoin de redémarrer l’instance de base de données après avoir défini ce paramètre. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
L'exemple suivant exécute la [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI commande pour définir les paramètres :
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myactivepg \
--parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-parameter-group-name myactivepg ^
--parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate"
```
**Astuce**
Assurez-vous de définir le paramètre `group_replication_group_seeds` dans chaque groupe de paramètres de base de données associé à une instance de base de données dans le cluster actif-actif.
## Étape 4 : Initialiser le groupe sur une instance de base de données et démarrer la réplication
Vous pouvez choisir n’importe quelle nouvelle base de données pour initialiser le groupe et démarrer la réplication. Pour ce faire, exécutez les étapes suivantes :
1. Choisissez une instance de base de données dans le cluster actif-actif et connectez-vous à cette instance de base de données dans un client SQL. Pour plus d’informations sur la connexion à une instance de base de données RDS for MySQL, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md).
1. Dans le client SQL, exécutez les procédures stockées suivantes et remplacez-les *group\$1replication\$1user\$1password* par le mot de passe de l'`rdsgrprepladmin`utilisateur. L’utilisateur `rdsgrprepladmin` est réservé aux connexions de réplication de groupe dans un cluster actif-actif. Le mot de passe de cet utilisateur doit être le même sur toutes les instances de base de données d’un cluster actif-actif.
```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(1);
```
Cet exemple définit la valeur `binlog retention hours` sur `168`, ce qui signifie que les fichiers journaux binaires sont retenus pendant sept jours sur l’instance de base de données. Vous pouvez ajuster cette valeur en fonction des exigences.
Cet exemple indique `1` dans la procédure stockée `mysql.rds_group_replication_start` d’initialiser un nouveau groupe avec l’instance de base de données actuelle.
Pour plus d’informations sur les procédures stockées appelées dans l’exemple, consultez [Gestion des clusters actifs-actifs](mysql-stored-proc-active-active-clusters.md).
## Étape 5 : Démarrer la réplication sur les autres instances de base de données du cluster actif-actif
Pour chacune des instances de base de données du cluster actif-actif, utilisez un client SQL pour vous connecter à l’instance et exécutez les procédures stockées suivantes. *group\$1replication\$1user\$1password*Remplacez-le par le mot de passe de l'`rdsgrprepladmin`utilisateur.
```
call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog
call mysql.rds_group_replication_create_user('group_replication_user_password');
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
call mysql.rds_group_replication_start(0);
```
Cet exemple définit la valeur `binlog retention hours` sur `168`, ce qui signifie que les fichiers journaux binaires sont retenus pendant sept jours sur chaque instance de base de données. Vous pouvez ajuster cette valeur en fonction des exigences.
Cet exemple indique `0` dans la procédure stockée `mysql.rds_group_replication_start` pour associer l’instance de base de données actuelle à un groupe existant.
**Astuce**
Assurez-vous d’exécuter ces procédures stockées sur toutes les autres instances de base de données du cluster actif-actif.
## Étape 6 : (Recommandé) Vérifiez l’état du cluster actif-actif
Pour vous assurer que chaque membre du cluster est correctement configuré, vérifiez l’état du cluster en vous connectant à une instance de base de données du cluster actif-actif et en exécutant la commande SQL suivante :
```
SELECT * FROM performance_schema.replication_group_members;
```
Votre sortie doit afficher `ONLINE` pour le `MEMBER_STATE` de chaque instance de base de données, comme dans l’exemple de sortie suivant :
```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```
Pour plus d’informations sur les valeurs possibles de `MEMBER_STATE`, consultez [États de serveur de réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) dans la documentation MySQL.
## Étape 7 : (Facultatif) Importer des données dans une instance de base de données du cluster actif-actif
Vous pouvez importer des données d’une base de données MySQL vers une instance de base de données du cluster actif-actif. Une fois les données importées, la Réplication de groupe les réplique sur les autres instances de base de données du cluster.
Pour en savoir plus sur l’importation de données, consultez [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md).
# Ajout d’une instance de base de données à un cluster actif-actif
Vous pouvez ajouter une instance de base de données à un cluster active-actif Amazon RDS for MySQL en restaurant un instantané de base de données ou en restaurant une instance de base de données à un instant dans le passé. Un cluster actif-actif peut inclure jusqu’à neuf instances de base de données.
Lorsque vous restaurez une instance de base de données à un instant dans le passé, elle inclut généralement des transactions plus récentes qu’une instance de base de données restaurée à partir d’un instantané de base de données. Lorsque l’instance de base de données possède des transactions plus récentes, vous devez appliquer moins de transactions que lorsque vous démarrez la réplication. Ainsi, l’utilisation de la reprise ponctuelle pour ajouter une instance de base de données à un cluster est généralement plus rapide que la restauration à partir d’un instantané de base de données.
**Topics**
+ [
## Ajout d’une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle
](#mysql-active-active-clusters-adding-pitr)
+ [
## Ajout d’une instance de base de données à un cluster actif-actif avec un instantané de base de données
](#mysql-active-active-clusters-adding-snapshot)
## Ajout d’une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle
Vous pouvez ajouter une instance de base de données à un cluster actif-actif en effectuant une reprise ponctuelle sur une instance de base de données du cluster.
Pour plus d’informations sur la reprise ponctuelle d’une instance de base de données dans une autre Région AWS, consultez [Réplication des sauvegardes automatisées vers une autre Région AWS](USER_ReplicateBackups.md).
**Pour ajouter une instance de base de données à un cluster actif-actif à l’aide de la reprise ponctuelle**
1. Créez une nouvelle instance de base de données en effectuant une reprise ponctuelle sur une instance de base de données dans le cluster actif-actif.
Vous pouvez effectuer une reprise ponctuelle sur n’importe quelle instance de base de données du cluster pour créer la nouvelle instance de base de données. Pour obtenir des instructions, consultez [Restauration d’une instance de base de données à un instant précis pour Amazon RDS](USER_PIT.md).
**Important**
Pendant la reprise ponctuelle, associez la nouvelle instance de base de données à un groupe de paramètres de base de données dont les paramètres de cluster actif-actif sont définis. Sinon, la réplication de groupe ne démarrera pas sur la nouvelle instance de base de données. Pour en savoir plus sur les paramètres et le réglage requis pour chacun, consultez [Réglages de paramètres requis pour les clusters actifs-actifs](mysql-active-active-clusters-parameters.md).
**Astuce**
Si vous prenez un instantané de l’instance de base de données avant de commencer la reprise ponctuelle, vous pourrez peut-être réduire le temps nécessaire pour appliquer les transactions sur la nouvelle instance de base de données.
1. Ajoutez l’instance de base de données au paramètre `group_replication_group_seeds` de chaque groupe de paramètres de base de données associé à une instance de base de données du cluster actif-actif, y compris le groupe de paramètres de base de données que vous avez associé à la nouvelle instance de base de données.
Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Dans un client SQL, connectez-vous à la nouvelle instance de base de données et appelez la procédure stockée [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Remplacez *group\$1replication\$1user\$1password* par le mot de passe de l’utilisateur `rdsgrprepladmin`.
```
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
```
1. À l’aide du client SQL, appelez la procédure stockée [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) pour démarrer la réplication :
```
call mysql.rds_group_replication_start(0);
```
## Ajout d’une instance de base de données à un cluster actif-actif avec un instantané de base de données
Vous pouvez ajouter une instance de base de données à un cluster actif-actif en créant un instantané de base de données d’une instance de base de données dans le cluster, puis en restaurant l’instantané de base de données.
Pour plus d’informations sur la copie d’un instantané dans une autre Région AWS, consultez [Considérations relatives à la copie d’instantanés entre régions](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions).
**Pour ajouter une instance de base de données à un cluster actif-actif avec un instantané de base de données**
1. Créez un instantané de base de données d’une instance de base de données dans le cluster actif-actif.
Vous pouvez créer un instantané de bases de données d’une instance de base de données dans le cluster. Pour obtenir des instructions, consultez [Création d’un instantané de base de données pour une instance de base de données mono-AZ pour Amazon RDS](USER_CreateSnapshot.md).
1. Restaurez une instance de base de données à partir de l’instantané de base de données.
Pendant l’opération de restauration de l’instantané, associez la nouvelle instance de base de données à un groupe de paramètres de base de données dont les paramètres de cluster actif-actif sont définis. Pour en savoir plus sur les paramètres et le réglage requis pour chacun, consultez [Réglages de paramètres requis pour les clusters actifs-actifs](mysql-active-active-clusters-parameters.md).
Pour en savoir plus sur la restauration d’une instance de base de données à partir d’un instantané de base de données, consultez [Restauration d’une instance de base de données](USER_RestoreFromSnapshot.md).
1. Ajoutez l’instance de base de données au paramètre `group_replication_group_seeds` de chaque groupe de paramètres de base de données associé à une instance de base de données du cluster actif-actif, y compris le groupe de paramètres de base de données que vous avez associé à la nouvelle instance de base de données.
Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Dans un client SQL, connectez-vous à la nouvelle instance de base de données et appelez la procédure stockée [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Remplacez *group\$1replication\$1user\$1password* par le mot de passe de l’utilisateur `rdsgrprepladmin`.
```
call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password');
```
1. À l’aide du client SQL, appelez la procédure stockée [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) pour démarrer la réplication :
```
call mysql.rds_group_replication_start(0);
```
# Surveillance des clusters actifs-actifs
La surveillance des clusters actifs-actifs dans Amazon RDS for MySQL est essentielle pour suivre les performances, l’intégrité de la réplication et la synchronisation des nœuds. Vous pouvez surveiller votre cluster actif-actif en vous connectant à une instance de base de données du cluster et en exécutant la commande SQL suivante :
```
SELECT * FROM performance_schema.replication_group_members;
```
Votre sortie doit afficher `ONLINE` pour le `MEMBER_STATE` de chaque instance de base de données, comme dans l’exemple de sortie suivant :
```
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
| group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
```
Pour plus d’informations sur les valeurs possibles de `MEMBER_STATE`, consultez [États de serveur de réplication de groupe](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) dans la documentation MySQL.
# Arrêt de la réplication de groupe sur une instance de base de données dans un cluster actif-actif
Vous pouvez arrêter la réplication de groupe sur une instance de base de données dans un cluster actif-actif. Lorsque vous arrêtez la réplication de groupe, l'instance de base de données est placée en super-read-only mode jusqu'à ce que la réplication soit redémarrée ou que cette instance de base de données soit supprimée du cluster actif-actif. Pour plus d'informations sur super-read-only le mode, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only).
**Pour arrêter temporairement la réplication de groupe pour un cluster actif-actif**
1. Connectez-vous à une instance de base de données dans le cluster actif-actif avec un client SQL.
Pour plus d’informations sur la connexion à une instance de base de données RDS for MySQL, consultez [Connexion à votre instance de base de données MySQL](USER_ConnectToInstance.md).
1. Dans le client SQL, appelez la procédure stockée [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) :
```
call mysql.rds_group_replication_stop();
```
# Modification du nom d’une instance de base de données dans un cluster actif-actif
Vous pouvez modifier le nom d’une instance de base de données dans un cluster actif-actif. Pour renommer plusieurs instances de base de données dans un cluster actif-actif, faites-le une instance à la fois. Renommez donc une instance de base de données et associez-la au cluster avant de renommer l’instance de base de données suivante.
**Pour renommer une instance de base de données dans un cluster actif-actif**
1. Connectez-vous à l’instance de base de données dans un client SQL et appelez la procédure stockée [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) :
```
call mysql.rds_group_replication_stop();
```
1. Renommez l’instance de base de données en suivant les instructions dans [Affectation d’un nouveau nom à une instance DB](USER_RenameInstance.md).
1. Modifiez le paramètre `group_replication_group_seeds` dans chaque groupe de paramètres de base de données associé à une instance de base de données dans le cluster actif-actif.
Dans le paramétrage, remplacez l’ancien point de terminaison de l’instance de base de données par le nouveau. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Connectez-vous à l’instance de base de données dans un client SQL et appelez la procédure stockée [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) :
```
call mysql.rds_group_replication_start(0);
```
# Suppression d’une instance de base de données d’un cluster actif-actif
Lorsque vous supprimez une instance de base de données d’un cluster actif-actif, elle redevient une instance de base de données autonome.
**Pour supprimer une instance de base de données d’un cluster actif-actif**
1. Connectez-vous à l’instance de base de données dans un client SQL et appelez la procédure stockée [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop) :
```
call mysql.rds_group_replication_stop();
```
1. Modifiez le paramètre `group_replication_group_seeds` des instances de base de données qui resteront dans le cluster actif-actif.
Dans le paramètre `group_replication_group_seeds`, supprimez l’instance de base de données que vous retirez du cluster actif-actif. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
1. Modifiez les paramètres de l’instance de base de données que vous supprimez du cluster actif-actif afin qu’elle ne fasse plus partie du cluster.
Vous pouvez associer l’instance de base de données à un groupe de paramètres différent ou modifier les paramètres du groupe de paramètres de base de données associé à l’instance de base de données. Les paramètres à modifier incluent `group_replication_group_name`, `rds.group_replication_enabled` et `group_replication_group_seeds`. Pour plus d’informations sur les paramètres de cluster actif-actif, consultez [Réglages de paramètres requis pour les clusters actifs-actifs](mysql-active-active-clusters-parameters.md).
Si vous modifiez les paramètres d’un groupe de paramètres de base de données, assurez-vous que ce dernier n’est pas associé à d’autres instances de base de données du cluster actif-actif.
1. Redémarrez l’instance de base de données que vous avez supprimée du cluster actif-actif pour que les nouveaux paramètres prennent effet.
Pour obtenir des instructions, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
# Exportation de données à partir d'une instance DB MySQL grâce à la réplication
Pour exporter des données à partir d'une instance de base de données RDS for MySQL vers une instance MySQL exécutée en externe sur Amazon RDS, vous pouvez utiliser la réplication. Dans ce scénario, l'instance de base de données MySQL est *l'instance de base de données MySQL source*, et l'instance MySQL qui s'exécute en externe sur Amazon RDS est la *base de données MySQL externe*.
La base de données MySQL externe peut s'exécuter soit localement dans votre centre de données, soit sur une instance Amazon EC2. La base de données MySQL externe doit exécuter la même version que l'instance de base de données MySQL source, ou une version ultérieure.
La réplication vers une base de données MySQL externe n'est prise en charge que pendant le temps nécessaire à l'exportation d'une base de données à partir de l'instance de base de données MySQL source. La réplication doit être terminée une fois que les données ont été exportées et que les applications peuvent commencer à accéder à l'instance externe.
La liste suivante montre les étapes à suivre. Chaque étape est présentée plus en détail dans les sections ultérieures.
1. Préparez une instance de base de données MySQL externe.
1. Préparez l'instance de base de données MySQL source pour la réplication.
1. Utilisez l'utilitaire mysqldump pour transférer la base de données de l'instance de base de données MySQL source vers la base de données MySQL externe.
1. Démarrez la réplication vers la base de données MySQL externe.
1. Une fois l'exportation terminée, arrêtez la réplication.
## Préparer une base de données MySQL externe
Effectuez les étapes suivantes pour préparer la base de données MySQL externe.
**Pour créer la base de données MySQL externe**
1. Installez la base de données MySQL externe.
1. Connectez-vous à la base de données MySQL externe en tant qu'utilisateur principal. Créez ensuite les utilisateurs requis pour prendre en charge les administrateurs, les applications et les services qui accèdent à la base de données.
1. Suivez les instructions de la documentation MySQL pour préparer la base de données MySQL externe en tant que réplica. Pour plus d’informations, consultez [Définition de la configuration du réplica](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-slavebaseconfig.html) dans la documentation MySQL.
1. Configurez une règle de sortie pour que la base de données MySQL externe fonctionne comme un réplica en lecture pendant l'exportation. La règle de sortie permet à la base de données MySQL externe de se connecter à l'instance de base de données MySQL source pendant la réplication. Spécifiez une règle de sortie qui autorise les connexions TCP (Transmission Control Protocol) au port et à l'adresse IP de l'instance de base de données MySQL source.
Spécifiez les règles de sortie appropriées pour votre environnement :
+ Si la base de données MySQL externe s’exécute dans une instance Amazon EC2 dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC, spécifiez les règles de sortie dans un groupe de sécurité VPC. Pour plus d’informations, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
+ Si la base de données MySQL externe est installée localement, spécifiez les règles de sortie dans un pare-feu.
1. Si la base de données MySQL externe est en cours d'exécution dans un VPC, configurez les règles pour les règles de liste de contrôle d'accès (ACL) VPC en plus de la règle de sortie du groupe de sécurité :
+ Configurez une règle d'entrée ACL autorisant le trafic TCP vers les ports 1024–65535 à partir de l'adresse IP de l'instance de base de données MySQL source.
+ Configurez une règle de sortie ACL autorisant le trafic TCP sortant vers le port et l'adresse IP de l'instance de base de données MySQL source.
Pour plus d'informations sur le réseau Amazon VPC ACLs, consultez la section Réseau dans le [guide](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) de l' ACLsutilisateur Amazon *VPC*.
1. (Facultatif) Définissez le paramètre `max_allowed_packet` sur la taille maximale pour éviter les erreurs de réplication. Nous recommandons ce paramètre.
## Préparer l'instance de base de données MySQL source
Effectuez les étapes suivantes pour préparer l'instance de base de données MySQL source en tant que source de réplication.
**Pour préparer l'instance de base de données MySQL source**
1. Assurez-vous que votre ordinateur client possède assez d'espace disque pour enregistrer les journaux binaires lors de la configuration de la réplication.
1. Connectez-vous à l’instance de base de données MySQL source et créez un compte de réplication en suivant les instructions de [Création d’un utilisateur pour la réplication](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-repuser.html) dans la documentation MySQL.
1. Configurez les règles d'entrée sur le système exécutant l'instance de base de données MySQL source pour permettre à la base de données MySQL externe de se connecter pendant la réplication. Spécifiez une règle d'entrée qui autorise les connexions TCP au port utilisé par l'instance de base de données MySQL source à partir de l'adresse IP de la base de données MySQL externe.
1. Spécifiez les règles de sortie :
+ Si l'instance de base de données MySQL source s'exécute dans un VPC, spécifiez les règles d'entrée dans un groupe de sécurité VPC. Pour plus d’informations, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
1. Si l'instance de base de données MySQL source est en cours d'exécution dans un VPC, configurez les règles ACL VPC en plus de la règle d'entrée de groupe de sécurité :
+ Configurez une règle d'entrée ACL pour autoriser les connexions TCP au port utilisé par l'instance Amazon RDS à partir de l'adresse IP de la base de données MySQL externe.
+ Configurez une règle de sortie ACL pour autoriser les connexions TCP des ports 1024–65535 vers l'adresse IP de la base de données MySQL externe.
Pour plus d'informations sur le réseau Amazon VPC ACLs, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) dans le guide de l'utilisateur Amazon *VPC*.
1. Assurez-vous que la période de rétention des sauvegardes soit assez longue pour qu'aucun journal binaire ne soit purgé pendant l'exportation. Si l'un des journaux est purgé avant la fin de l'exportation, vous devez redémarrer la réplication depuis le début. Pour plus d'informations sur la configuration de la période de rétention des sauvegardes, consultez [Présentation des sauvegardes](USER_WorkingWithAutomatedBackups.md).
1. Utilisez la procédure stockée `mysql.rds_set_configuration` pour définir une période de conservation du journal binaire suffisamment longue pour que les journaux binaires ne soient pas purgés pendant l'exportation. Pour plus d’informations, consultez [Accès aux journaux binaires MySQL](USER_LogAccess.MySQL.Binarylog.md).
1. Créez un réplica en lecture Amazon RDS à partir de l'instance de base de données MySQL source afin de vous assurer que les journaux binaires de l'instance de base de données MySQL source ne seront pas purgés. Pour plus d’informations, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
1. Une fois que le réplica en lecture Amazon RDS a été créé, appelez la procédure stockée `mysql.rds_stop_replication` pour arrêter le processus de réplication. L'instance de base de données MySQL source ne purge plus ses fichiers journaux binaires, ils sont donc disponibles pour le processus de réplication.
1. (Facultatif) Définissez le paramètre `max_allowed_packet` et le paramètre `slave_max_allowed_packet` sur la taille maximale pour éviter les erreurs de réplication. La taille maximale pour les deux paramètres est de 1 Go. Nous recommandons ces valeurs pour les deux paramètres. Pour plus d’informations sur la définition des paramètres, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
## Copier la base de données
Effectuez les étapes suivantes pour copier la base de données.
**Pour copier la base de données**
1. Connectez-vous au réplica en lecture RDS de l'instance de base de données MySQL source et exécutez l'instruction `SHOW REPLICA STATUS\G` MySQL. Notez les valeurs pour les éléments suivants :
+ `Master_Host`
+ `Master_Port`
+ `Master_Log_File`
+ `Exec_Master_Log_Pos`
**Note**
Les versions précédentes de MySQL utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `SHOW SLAVE STATUS`.
1. Utilisez l'utilitaire mysqldump pour créer un instantané qui copie les données Amazon RDS à partir de votre ordinateur client local. Assurez-vous que votre ordinateur client possède assez d'espace disque pour contenir les fichiers `mysqldump` des bases de données à répliquer. Ce processus peut prendre plusieurs heures pour les bases de données très volumineuses. Suivez les instructions de [Création d’un instantané de données à l’aide de mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) dans la documentation MySQL.
L'exemple suivant exécute `mysqldump` sur un client et écrit le vidage dans un fichier.
Pour Linux, macOS ou Unix :
```
mysqldump -h source_MySQL_DB_instance_endpoint \
-u user \
-ppassword \
--port=3306 \
--single-transaction \
--routines \
--triggers \
--databases database database2 > path/rds-dump.sql
```
Pour Windows :
```
mysqldump -h source_MySQL_DB_instance_endpoint ^
-u user ^
-ppassword ^
--port=3306 ^
--single-transaction ^
--routines ^
--triggers ^
--databases database database2 > path\rds-dump.sql
```
Vous pouvez charger le fichier de sauvegarde dans la base de données MySQL externe. Pour plus d'informations, consultez [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) (Rechargement des sauvegardes au format SQL) dans la documentation MySQL. Vous pouvez exécuter un autre utilitaire pour charger les données dans la base de données MySQL externe.
## Terminer l'exportation
Effectuez les étapes suivantes pour terminer l'exportation.
**Pour terminer l'exportation**
1. Utilisez l'instruction MySQL `CHANGE MASTER` pour configurer l'instance MySQL externe. Spécifiez l'ID et le mot de passe de l'utilisateur auquel ont été attribuées les autorisations `REPLICATION SLAVE`. Spécifiez les valeurs `Master_Host`, `Master_Port`, `Relay_Master_Log_File` et `Exec_Master_Log_Pos` obtenues à partir de l'instruction `SHOW REPLICA STATUS\G` MySQL que vous avez exécutée sur le réplica en lecture RDS. Pour en savoir plus, consultez [Instruction CHANGE MASTER TO](https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html) dans la documentation MySQL.
**Note**
Les versions précédentes de MySQL utilisaient `SHOW SLAVE STATUS` à la place de `SHOW REPLICA STATUS`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `SHOW SLAVE STATUS`.
1. Utilisez la commande `START REPLICA` MySQL pour lancer la réplication à partir de l'instance de base de données MySQL source vers la base de données MySQL externe.
Cela démarre la réplication à partir de l'instance de base de données MySQL source et exporte toutes les modifications de source qui se sont produites après l'arrêt de la réplication à partir du réplica en lecture Amazon RDS.
**Note**
Les versions précédentes de MySQL utilisaient `START SLAVE` à la place de `START REPLICA`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `START SLAVE`.
1. Exécutez la commande `SHOW REPLICA STATUS\G` MySQL sur la base de données MySQL externe pour vérifier qu'elle fonctionne comme un réplica en lecture. Pour obtenir des informations sur l’interprétation des résultats, consultez [Instruction SHOW SLAVE \$1 REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html) dans la documentation MySQL.
1. Une fois que la réplication sur la base de données MySQL externe a rattrapé l'instance de base de données MySQL source, utilisez la commande `STOP REPLICA` MySQL pour arrêter la réplication à partir de l'instance de base de données MySQL source.
**Note**
Les versions précédentes de MySQL utilisaient `STOP SLAVE` à la place de `STOP REPLICA`. Si vous utilisez une version de MySQL antérieure à la version 8.0.23, utilisez alors `STOP SLAVE`.
1. Sur le réplica en lecture Amazon RDS, appelez la procédure stockée `mysql.rds_start_replication`. Cela permet à Amazon RDS de démarrer la purge des fichiers journaux binaires à partir de l'instance de base de données MySQL source.
# Options pour les instances de base de données MySQL
La section suivante décrit les options ou fonctions supplémentaires, disponibles pour les instances Amazon RDS exécutant le moteur de base de données MySQL. Pour activer ces options, vous pouvez les ajouter à un groupe d’options personnalisé, puis associer ce dernier à votre instance de base de données. Pour plus d'informations sur l'utilisation de groupes d'options, consultez [Utilisation de groupes d’options](USER_WorkingWithOptionGroups.md).
Amazon RDS prend en charge les options suivantes pour MySQL :
****
| Option | ID d’option | Versions du moteur |
| --- | --- | --- |
| [Prise en charge du plugin d'audit MariaDB pour MySQL](Appendix.MySQL.Options.AuditPlugin.md) | `MARIADB_AUDIT_PLUGIN` | Toutes les versions 8.4 de MySQLMySQL 8.0.28 et versions 8.0 ultérieuresToutes les versions 5.7 de MySQL |
| [Prise en charge memcached MySQL](Appendix.MySQL.Options.memcached.md) | `MEMCACHED` | Toutes les versions MySQL 5.7 et 8.0 |
# Prise en charge du plugin d'audit MariaDB pour MySQL
Amazon RDS propose un plug-in d'audit pour les instances de base de données MySQL basé sur le plug-in d'audit MariaDB open source. Pour plus d'informations, consultez le [plug-in d'audit pour le GitHub référentiel MySQL Server](https://github.com/aws/audit-plugin-for-mysql).
**Note**
Le plug-in d'audit pour MySQL est basé sur le plug-in d'audit MariaDB. Tout au long de cet article, nous l'appelons Plug-in d'audit MariaDB.
Le plugin d'audit MariaDB enregistre l'activité de la base de données, y compris la connexion des utilisateurs à la base de données et les requêtes exécutées sur la base de données. L'enregistrement de l'activité de la base de données est stocké dans un fichier journal.
## Paramètres de l'option du plugin d'audit
Amazon RDS prend en charge les paramètres suivants pour l'option de plugin d'audit MariaDB.
| Paramètre d'option | Valeurs valides | Valeur par défaut | Description |
| --- | --- | --- | --- |
| `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | Emplacement du fichier journal. Le fichier journal contient l'enregistrement de l'activité spécifiée dans `SERVER_AUDIT_EVENTS`. Pour plus d’informations, consultez [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md) et [Fichiers journaux de base de données MySQL](USER_LogAccess.Concepts.MySQL.md). |
| `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1–1000000000 | 1000000 | Taille en octets qui, lorsqu'elle est atteinte, entraîne la rotation du fichier. Pour plus d’informations, consultez [Présentation des journaux de base de données RDS for MySQL](USER_LogAccess.MySQL.LogFileSize.md). |
| `SERVER_AUDIT_FILE_ROTATIONS` | 0–100 | 9 | Nombre de rotations de journaux à enregistrer quand `server_audit_output_type=file`. S'il est défini sur 0, le fichier journal ne pivote jamais. Pour plus d’informations, consultez [Présentation des journaux de base de données RDS for MySQL](USER_LogAccess.MySQL.LogFileSize.md) et [Téléchargement d'un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md). |
| `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | Types d'activités à enregistrer dans le journal. L'installation du plugin d'audit MariaDB est elle-même enregistrée. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) Pour MySQL, `TABLE` n'est pas pris en charge. |
| `SERVER_AUDIT_INCL_USERS` | Plusieurs valeurs séparées par des virgules | Aucune | Incluez uniquement l'activité des utilisateurs spécifiés. Par défaut, l'activité est enregistrée pour tous les utilisateurs. `SERVER_AUDIT_INCL_USERS` et `SERVER_AUDIT_EXCL_USERS` sont mutuellement exclusifs. Si vous ajoutez des valeurs à `SERVER_AUDIT_INCL_USERS`, assurez-vous qu'aucune valeur n'est ajoutée à `SERVER_AUDIT_EXCL_USERS`. |
| `SERVER_AUDIT_EXCL_USERS` | Plusieurs valeurs séparées par des virgules | Aucune | Excluez l'activité des utilisateurs spécifiés. Par défaut, l'activité est enregistrée pour tous les utilisateurs. `SERVER_AUDIT_INCL_USERS` et `SERVER_AUDIT_EXCL_USERS` sont mutuellement exclusifs. Si vous ajoutez des valeurs à `SERVER_AUDIT_EXCL_USERS`, assurez-vous qu'aucune valeur n'est ajoutée à `SERVER_AUDIT_INCL_USERS`. L'utilisateur `rdsadmin` interroge la base de données par seconde pour vérifier l'intégrité de la base de données. En fonction de vos autres paramètres, cette activité peut éventuellement provoquer un accroissement considérable et rapide de la taille de votre fichier journal. Si vous n'avez pas besoin d'enregistrer cette activité, ajoutez l'utilisateur `rdsadmin` à la liste `SERVER_AUDIT_EXCL_USERS`. `CONNECT`L'activité est toujours enregistrée pour tous les utilisateurs, même si l'utilisateur est spécifié pour ce paramètre d'option. |
| `SERVER_AUDIT_LOGGING` | `ON` | `ON` | La journalisation est active. La seule valeur valide est `ON`. Amazon RDS ne prend pas en charge la désactivation de la journalisation. Si vous souhaitez désactiver la journalisation, supprimez le plugin d'audit MariaDB. Pour plus d’informations, consultez [Suppression du plugin d'audit MariaDB](#Appendix.MySQL.Options.AuditPlugin.Remove). |
| `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0–2147483647 | 1 024 | Limite de longueur de la chaîne de requête dans un enregistrement. |
## Ajout du plugin d'audit MariaDB
Le processus général pour ajouter le plug-in d'audit MariaDB à une instance de base de données est le suivant :
+ Créez un groupe d'options ou copiez ou modifiez un groupe d'options existant.
+ Ajouter l'option au groupe d'options
+ Associer un groupe d'options à une instance de base de données
Une fois que vous ajoutez le plug-in d'audit MariaDB, vous n'avez pas besoin de redémarrer votre instance de base de données. Dès que le groupe d'options est actif, l'audit commence immédiatement.
**Important**
L'ajout du plug-in d'audit MariaDB à une instance de base de données peut entraîner une interruption de service. Nous vous recommandons d'ajouter le plug-in d'audit MariaDB pendant une fenêtre de maintenance ou lorsque la charge de travail de base de données est faible.
**Pour ajouter le plug-in d'audit MariaDB**
1. Déterminez le groupe d'options que vous voulez utiliser. Vous pouvez créer un groupe d'options ou utiliser un groupe d'options existant. Si vous souhaitez utiliser un groupe d'options existant, passez à l'étape suivante. Sinon, créez un groupe d'options de base de données personnalisé. Choisissez **mysql** pour **Moteur**, puis **5.7** ou **8.0** ou **8.4** pour **Version majeure du moteur**. Pour plus d’informations, consultez [Création d’un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create).
1. Ajoutez l'option **MARIADB\$1AUDIT\$1PLUGIN** pour le groupe d'options et configurez les paramètres de l'option. Pour plus d'informations sur l'ajout d'options, consultez [Ajout d’une option à un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). Pour plus d'informations sur chaque paramètre, consultez [Paramètres de l'option du plugin d'audit](#Appendix.MySQL.Options.AuditPlugin.Options).
1. Appliquez le groupe d'options à une instance de base de données nouvelle ou existante.
+ Pour une nouvelle instance de base de données, vous appliquez le groupe d'options lorsque vous lancez l'instance. Pour plus d’informations, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Pour une instance de base de données existante, vous appliquez le groupe d'options en modifiant l'instance et en attachant le nouveau groupe d'options. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
## Format des journaux d'audit
Les fichiers journaux sont représentés sous forme de fichiers CSV (variables séparées par des virgules) au format UTF-8.
**Astuce**
Les entrées de fichier journal ne sont pas classées par ordre séquentiel. Pour ordonner les entrées, utilisez la valeur d’horodatage. Pour consulter les derniers événements, vous devrez peut-être passer en revue tous les fichiers journaux. Pour plus de flexibilité dans le tri et la recherche des données des journaux, activez le paramètre permettant de télécharger les journaux d'audit CloudWatch et de les consulter à l'aide de l' CloudWatch interface.
Pour afficher des données d’audit avec plus de types de champs et avec une sortie au format JSON, vous pouvez également utiliser la fonction Flux d’activité de base de données. Pour plus d’informations, consultez [Surveillance d’Amazon RDS à l’aide des flux d’activité de base de données](DBActivityStreams.md).
Les fichiers journaux d’audit incluent les informations séparées par des virgules suivantes en lignes, dans l’ordre indiqué :
| Champ | Description |
| --- | --- |
| timestamp | `YYYYMMDD` suivi de `HH:MI:SS` (format 24 heures) correspondant à l'événement enregistré. |
| serverhost | Le nom de l’instance pour laquelle\$1\$1\$1 l’événement est consigné. |
| username | Le nom d’utilisateur connecté de l’utilisateur. |
| hôte | L’hôte à partir duquel\$1\$1 l’utilisateur s’est connecté. |
| connectionid | Le numéro d’identification de la connexion pour l’opération consignée. |
| queryid | Le numéro d’identification de la requête qui peut être utilisé pour trouver les événements de la table relationnelle et les requêtes liées. Pour les événements `TABLE`, plusieurs lignes sont ajoutées. |
| fonctionnement | Le type d’action enregistrée. Les valeurs possibles sont : `CONNECT`, `QUERY`, `READ`, `WRITE`, `CREATE`, `ALTER`, `RENAME` et `DROP`. |
| database | La base de données active, telle que définie par la commande `USE`. |
| objet | Pour les événements `QUERY`, cette valeur indique la demande effectuée par la base de données. Pour les événements `TABLE`, cette valeur indique le nom de la table. |
| retcode | Le code de retour de l’opération consignée. |
| connection\$1type | État de sécurité de la connexion au serveur. Les valeurs possibles sont : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) |
## Affichage et téléchargement du journal du plugin d'audit MariaDB
Une fois que vous activez le plugin d'audit MariaDB, vous accéder aux résultats dans les fichiers journaux de la même manière que tous les autres fichiers journaux texte. Les fichiers journaux d'audit se trouvent dans `/rdsdbdata/log/audit/`. Pour plus d'informations sur l'affichage du fichier journal dans la console, consultez [Liste et affichage des fichiers journaux de base de données](USER_LogAccess.Procedural.Viewing.md). Pour plus d'informations sur le téléchargement du fichier journal, consultez [Téléchargement d'un fichier journal de base de données](USER_LogAccess.Procedural.Downloading.md).
## Modification des paramètres de plug-in d'audit MariaDB
Une fois que vous activez le plug-in d'audit MariaDB, vous pouvez modifier les paramètres. Pour plus d'informations sur la modification des paramètres d'options, consultez [Modification d’un paramètre d’option](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). Pour plus d'informations sur chaque paramètre, consultez [Paramètres de l'option du plugin d'audit](#Appendix.MySQL.Options.AuditPlugin.Options).
## Suppression du plugin d'audit MariaDB
Amazon RDS ne prend pas en charge la désactivation de la journalisation du plugin d'audit MariaDB. Toutefois, vous pouvez supprimer le plugin dans une instance de base de données. Lorsque vous supprimez le plugin d'audit MariaDB, l'instance de base de données est automatiquement redémarrée pour cesser l'audit.
Pour supprimer le plugin d'audit MariaDB d'une instance de base de données, effectuez l'une des actions suivantes :
+ Supprimez l'option de plugin d'audit MariaDB du groupe d'options auquel elle appartient. Ce changement affecte toutes les instances de bases de données qui utilisent le groupe d'options. Pour plus d'informations, consultez [Suppression d’une option d’un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption)
+ Modifiez l'instance de base de données et spécifiez un groupe d'options différent qui n'inclut pas le plugin. Ce changement affecte une seule instance de base de données. Vous pouvez spécifier le groupe d’options (vide) par défaut, ou un groupe d’options personnalisées différent. Pour plus d’informations, consultez [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
# Prise en charge memcached MySQL
Amazon RDS prend en charge l'utilisation de l'interface `memcached` pour les tableaux InnoDB introduits dans MySQL 5.6. L'API `memcached` permet aux applications d'utiliser les tables InnoDB de la même façon que les magasins de données clé-valeur NoSQL.
**Note**
L’interface memcached n’est plus disponible dans MySQL 8.4. Lorsque vous mettez à niveau vos instances de base de données vers MySQL 8.4, vous devez les désactiver `memcached` dans les groupes d’options existants.
L'interface `memcached` est un cache simple basé sur les clés. Les applications utilisent `memcached` pour insérer, manipuler et récupérer les paires de données clé-valeur du cache. MySQL 5.6 a présenté un plug-in qui implémente un service démon exposant les données des tables InnoDB via le protocole `memcached`. Pour plus d’informations sur le plug-in MySQL `memcached`, consultez [InnoDB Integration with memcached](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html).
**Pour activer la prise en charge memcached d'une instance de base de données RDS for MySQL**
1. Déterminez le groupe de sécurité à utiliser pour contrôler l'accès à l'interface `memcached`. Si l'ensemble d'applications qui utilise déjà l'interface SQL est identique à celui qui accède à l'interface `memcached`, vous pouvez utiliser le groupe de sécurité VPC existant utilisé par l'interface SQL. Si un ensemble différent d'applications accède à l'interface `memcached`, définissez un nouveau groupe de sécurité VPC ou DB. Pour plus d'informations sur la gestion des groupes de sécurité, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md)
1. Créez un groupe d'options de base de données personnalisé, en sélectionnant MySQL comme type et version du moteur. Pour plus d'informations sur la création d'un groupe d'options, consultez [Création d’un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create).
1. Ajoutez l'option `MEMCACHED` au groupe d'options. Spécifiez le port que l'interface `memcached` utilisera, et le groupe de sécurité à utiliser pour contrôler l'accès à l'interface. Pour plus d'informations sur l'ajout d'options, consultez [Ajout d’une option à un groupe d’options](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption).
1. Modifiez les options pour configurer les paramètres `memcached`, le cas échéant. Pour plus d'informations sur la modification des paramètres d'options, consultez [Modification d’un paramètre d’option](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption).
1. Appliquez le groupe d'options à une instance. Amazon RDS active la prise en charge de `memcached` pour cette instance lorsque le groupe d’options est appliqué :
+ Vous activez la prise en charge `memcached` pour une nouvelle instance en spécifiant le groupe d'options personnalisé lorsque vous lancez l'instance. Pour plus d'informations sur le lancement d'une instance MySQL, consultez [Création d'une instance de base de données Amazon RDS](USER_CreateDBInstance.md).
+ Vous activez la prise en charge `memcached` pour une instance existante en spécifiant le groupe d'options personnalisé lorsque vous modifiez l'instance. Pour de plus amples informations sur la modification d'une instance de base de données, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
1. Spécifiez les colonnes de vos tables MySQL accessibles via l'interface `memcached`. Le plug-in `memcached` crée une table de catalogue appelée `containers` dans une base de données dédiée appelée `innodb_memcache`. Vous insérez une ligne dans la table `containers` pour mapper une table InnoDB et y accéder via `memcached`. Vous spécifiez une colonne dans la table InnoDB qui est utilisée pour stocker les valeurs de clé `memcached`, et une ou plusieurs colonnes qui sont utilisées pour stocker les valeurs de données associées à la clé. Vous spécifiez également un nom qu'une application `memcached` utilise pour faire référence à cet ensemble de colonnes. Pour plus d’informations sur l’insertion de lignes dans la table `containers`, consultez [Internals of the InnoDB memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html). Pour obtenir un exemple de mappage d’une table InnoDB et y accéder via `memcached`, consultez [Writing Applications for the InnoDB memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-developing.html).
1. Si les applications accédant à l'`memcached`interface se trouvent sur des ordinateurs ou des EC2 instances différents de ceux des applications utilisant l'interface SQL, ajoutez les informations de connexion de ces ordinateurs au groupe de sécurité VPC associé à l'instance MySQL. Pour plus d'informations sur la gestion des groupes de sécurité, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
Vous désactivez la prise en charge `memcached` pour une instance en modifiant l'instance et en spécifiant le groupe d'options par défaut pour votre version MySQL. Pour de plus amples informations sur la modification d'une instance de base de données, veuillez consulter [Modification d'une instance de base de données Amazon RDS](Overview.DBInstance.Modifying.md).
## Considérations de sécurité memcached MySQL
Le protocole `memcached` ne prend pas en charge l'authentification utilisateur. Pour plus d'informations sur les considérations de sécurité relatives à MySQL `memcached`, consultez [Security Considerations for the InnoDB memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-security.html) (Considérations de sécurité relatives au plug-in InnoDB memcached) dans la documentation MySQL.
Vous pouvez prendre les mesures suivantes pour aider à augmenter la sécurité de l'interface `memcached` :
+ Spécifiez un port différent du port par défaut 11211 lorsque vous ajoutez l'option `MEMCACHED` au groupe d'options.
+ Assurez-vous d'associer l'`memcached`interface à un groupe de sécurité VPC qui limite l'accès aux adresses clients et aux instances connues et EC2 fiables. Pour plus d'informations sur la gestion des groupes de sécurité, consultez [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
## Informations de connexion memcached MySQL
Pour accéder à l'interface `memcached`, une application doit spécifier le nom DNS de l'instance Amazon RDS et le numéro de port `memcached`. Par exemple, si une instance possède un nom DNS de `my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com` et l'interface memcached utilise le port 11212, les informations de connexion spécifiées dans PHP seront :
```
1. connect('my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com',11212);
5. ?>
```
**Pour trouver le nom DNS et le port memcached d'une instance de base de données MySQL**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le coin supérieur droit du AWS Management Console, sélectionnez la région qui contient l'instance de base de données.
1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez le nom de l'instance de base de données MySQL pour afficher ses détails.
1. Dans la section **Connexion**, notez la valeur du champ **Point de terminaison**. Le nom DNS est le même que le point de terminaison. Veuillez également noter que le port dans la section **Connexion** n'est pas utilisé pour accéder à l'interface `memcached`.
1. Dans la section **Détails**, notez le nom répertorié dans le champ **Groupe d'options**.
1. Dans le panneau de navigation, choisissez **Groupes d’options**.
1. Choisissez le nom du groupe d'options utilisé par l'instance de base de données MySQL pour afficher les détails du groupe d'options. Dans la section **Options**, notez la valeur du paramètre **Port** pour l'option **MEMCACHED**.
## Paramètres d'option memcached MySQL
Amazon RDS expose les paramètres `memcached` MySQL comme paramètres d'option dans l'option Amazon RDS `MEMCACHED`.
### Paramètres memcached MySQL
+ `DAEMON_MEMCACHED_R_BATCH_SIZE` – Nombre entier qui spécifie combien d'opérations de lecture (get) `memcached` doivent être effectuées avant d'exécuter un COMMIT pour lancer une nouvelle transaction. Les valeurs autorisées sont comprises entre 1 et 4294967295, et celle par défaut est 1. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `DAEMON_MEMCACHED_W_BATCH_SIZE` – Nombre entier qui spécifie combien d'opérations d'écriture `memcached` comme add, set ou incr doivent être effectuées avant d'exécuter un COMMIT pour lancer une nouvelle transaction. Les valeurs autorisées sont comprises entre 1 et 4294967295, et celle par défaut est 1. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `INNODB_API_BK_COMMIT_INTERVAL` – Nombre entier qui spécifie la fréquence d'auto-commit des connexions inactives qui utilisent l'interface `memcached` InnoDB. Les valeurs autorisées sont comprises entre 1 et 1073741824, et celle par défaut est 5. L'option prend effet immédiatement, sans que vous ayez besoin de redémarrer l'instance.
+ `INNODB_API_DISABLE_ROWLOCK` – Valeur booléenne qui désactive (1 (vrai)) ou active (0 (faux)) l'utilisation des verrouillages de ligne lorsque vous utilisez l'interface `memcached` InnoDB. La valeur par défaut est 0 (faux). L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `INNODB_API_ENABLE_MDL` – Valeur booléenne qui, lorsqu'elle est configurée sur 0 (faux), verrouille la table utilisée par le plug-in `memcached` InnoDB pour ne pas qu'il puisse être abandonné ou modifié par une instruction DDL via l'interface SQL. La valeur par défaut est 0 (faux). L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `INNODB_API_TRX_LEVEL` : nombre entier qui spécifie le niveau d’isolement de la transaction pour les requêtes traitées par l’interface `memcached`. Les valeurs autorisées sont comprises entre 0 et 3. La valeur par défaut est 0. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
Amazon RDS configure ces paramètres `memcached` MySQL, ils ne peuvent pas être modifiés : `DAEMON_MEMCACHED_LIB_NAME`, `DAEMON_MEMCACHED_LIB_PATH` et `INNODB_API_ENABLE_BINLOG`. Les paramètres que les administrateurs MySQL configurent en utilisant `daemon_memcached_options` sont disponibles comme paramètres d'options `MEMCACHED` individuels dans Amazon RDS.
### Paramètres MySQL daemon\$1memcached\$1options
+ `BINDING_PROTOCOL`– Chaîne qui spécifie le protocole de liaison à utiliser. Les valeurs autorisées sont `auto`, `ascii` ou `binary`. La valeur par défaut est `auto`, ce qui signifie que le serveur négocie automatiquement le protocole avec le client. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `BACKLOG_QUEUE_LIMIT` – Nombre entier qui spécifie combien de connexions réseau peuvent être en attente de traitement par `memcached`. L'augmentation de cette limite peut réduire les erreurs reçues par un client qui ne peut pas se connecter à l'instance `memcached`, mais n'améliore pas les performances du serveur. Les valeurs autorisées sont comprises entre 1 et 2048, et celle par défaut est 1024. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `CAS_DISABLED` – Valeur booléenne qui active (1 (vrai)) ou désactive (0 (faux)) l'utilisation de la fonction CAS (Compare and Swap), ce qui réduit la taille par élément de 8 octets. La valeur par défaut est 0 (faux). L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `CHUNK_SIZE` – Nombre entier qui spécifie la taille minimum du bloc, en octets, à attribuer à la clé, à la valeur et aux indicateurs de l'élément le plus petit. Les valeurs autorisées sont comprises entre 1 et 48. La valeur par défaut est 48 et vous pouvez considérablement améliorer l'efficacité de la mémoire avec une valeur inférieure. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `CHUNK_SIZE_GROWTH_FACTOR` – Nombre flottant qui contrôle la taille des nouveaux blocs. La taille d'un nouveau bloc correspond à la taille du bloc précédent multipliée par `CHUNK_SIZE_GROWTH_FACTOR`. Les valeurs autorisées sont comprises entre 1 et 2, et celle par défaut est 1.25. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `ERROR_ON_MEMORY_EXHAUSTED` – Valeur booléenne qui, lorsqu'elle est configurée sur 1 (vrai), spécifie que `memcached` renverra une erreur plutôt que d'expulser les éléments lorsqu'il n'y a plus de mémoire pour les stocker. S'il est configuré sur 0 (faux), `memcached` expulse les éléments s'il n'y a plus de mémoire. La valeur par défaut est 0 (faux). L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `MAX_SIMULTANEOUS_CONNECTIONS` – Nombre entier qui spécifie le nombre maximum de connexions simultanées. La configuration de cette valeur sur n'importe quel chiffre inférieur à 10 empêche MySQL de démarrer. Les valeurs autorisées sont comprises entre 10 et 1024, et celle par défaut est 1024. L'option ne prend pas effet tant que l'instance n'est pas redémarrée.
+ `VERBOSITY` – Chaîne qui spécifie le niveau d'informations consignées dans le journal d'erreurs MySQL par le service `memcached`. La valeur par défaut est v. L'option ne prend pas effet tant que l'instance n'est pas redémarrée. Les valeurs autorisées sont :
+ `v` : journalise les erreurs et avertissements pendant l’exécution de la boucle principale d’événements.
+ `vv` – Outre les informations consignées par v, journalise également la commande de chaque client et la réponse.
+ `vvv` – Outre les informations consignées par vv, journalise également les transitions d'état interne.
Amazon RDS configure ces paramètres MySQL `DAEMON_MEMCACHED_OPTIONS`, ils ne peuvent pas être modifiés : `DAEMON_PROCESS`, `LARGE_MEMORY_PAGES`, `MAXIMUM_CORE_FILE_LIMIT`, `MAX_ITEM_SIZE`, `LOCK_DOWN_PAGE_MEMORY`, `MASK`, `IDFILE`, `REQUESTS_PER_EVENT`, `SOCKET` et `USER`.
# Paramètres pour MySQL
Par défaut, une instance de base de données MySQL utilise un groupe de paramètres de base de données qui est spécifique à une base de données MySQL. Ce groupe de paramètres contient des paramètres pour le moteur de base de données MySQL. Pour plus d’informations sur l’utilisation des groupes de paramètres et sur la définition des paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Les paramètres RDS for MySQL sont définis aux valeurs par défaut du moteur de stockage que vous avez sélectionné. Pour plus d’informations sur les paramètres MySQL, consultez la [documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html). Pour plus d’informations sur les moteurs de stockage MySQL, consultez [Moteurs de stockage pris en charge pour RDS for MySQL](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.Storage).
Vous pouvez afficher les paramètres disponibles pour une version spécifique de RDS pour MySQL à l'aide de la console RDS ou de l'AWS CLI. Pour plus d’informations sur l’affichage des paramètres d’un groupe de paramètres MySQL dans la console RDS, consultez [Affichage des valeurs de paramètres pour un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Viewing.md).
À l'aide de l'AWS CLI, vous pouvez afficher les paramètres d'une version RDS for MySQL en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html). Spécifiez l’une des valeurs suivantes pour l’option `--db-parameter-group-family` :
+ `mysql8.4`
+ `mysql8.0`
+ `mysql5.7`
Par exemple, pour afficher les paramètres de RDS for MySQL version 8.0, exécutez la commande suivante.
```
aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0
```
Votre résultat ressemble à ce qui suit.
```
{
"EngineDefaults": {
"Parameters": [
{
"ParameterName": "activate_all_roles_on_login",
"ParameterValue": "0",
"Description": "Automatically set all granted roles as active after the user has authenticated successfully.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "boolean",
"AllowedValues": "0,1",
"IsModifiable": true
},
{
"ParameterName": "allow-suspicious-udfs",
"Description": "Controls whether user-defined functions that have only an xxx symbol for the main function can be loaded",
"Source": "engine-default",
"ApplyType": "static",
"DataType": "boolean",
"AllowedValues": "0,1",
"IsModifiable": false
},
{
"ParameterName": "auto_generate_certs",
"Description": "Controls whether the server autogenerates SSL key and certificate files in the data directory, if they do not already exist.",
"Source": "engine-default",
"ApplyType": "static",
"DataType": "boolean",
"AllowedValues": "0,1",
"IsModifiable": false
},
...
```
Pour répertorier uniquement les paramètres modifiables pour RDS for MySQL version 8.0, exécutez la commande suivante.
Pour Linux, macOS ou Unix :
```
aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 \
--query 'EngineDefaults.Parameters[?IsModifiable==`true`]'
```
Pour Windows :
```
aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ^
--query "EngineDefaults.Parameters[?IsModifiable==`true`]"
```
# 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.
# Fuseau horaire local pour les instances de bases de données MySQL
Par défaut, le fuseau horaire d'une instance de base de données MySQL est le fuseau UTC (temps universel). Vous pouvez à la place définir le fuseau horaire de votre instance de base de données sur le fuseau horaire local de votre application.
Pour définir le fuseau horaire local d'une instance de base de données, définissez le paramètre `time_zone` du groupe de paramètres de votre instance de base de données avec l'une des valeurs prises en charge et répertoriées plus bas dans cette section. Lorsque vous définissez le paramètre `time_zone` d'un groupe de paramètres, toutes les instances de base de données et tous les réplicas en lecture qui ont recours à ce groupe de paramètres sont modifiés de façon à utiliser le nouveau fuseau horaire local. Pour plus d'informations sur la définition des paramètres d'un groupe de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Une fois que vous avez défini le fuseau horaire local, toutes les nouvelles connexions à la base de données reflètent la modification. Si des connexions à votre base de données sont ouvertes lorsque vous modifiez le fuseau horaire local, la mise à jour du fuseau horaire local n'apparaît pas tant que vous n'avez pas fermé la connexion et n'en avez pas ouvert une nouvelle.
Vous pouvez définir un fuseau horaire local différent pour une instance de base de données et un ou plusieurs de ses réplicas en lecture. Pour ce faire, utilisez un autre groupe de paramètres pour l’instance de base de données et les réplicas, et définissez le paramètre `time_zone` de chaque groupe de paramètres avec un autre fuseau horaire local.
Si la réplication s'effectue entre les Régions AWS, l'instance de base de données source et le réplica en lecture utilisent des groupes de paramètres différents (les groupes de paramètres sont propres à chaque Région AWS). Pour que chaque instance utilise le même fuseau horaire local, vous devez définir le paramètre `time_zone` dans les groupes de paramètres de l’instance et du réplica en lecture.
Lorsque vous restaurez une instance de base de données à partir d'un instantané de base de données, le fuseau horaire local a la valeur UTC. Vous pouvez mettre à jour le fuseau horaire sur votre fuseau horaire local une fois la restauration terminée. Si vous restaurez une instance de base de données à un instant dans le passé, le fuseau horaire local de l’instance de base de données restaurée est le paramètre de fuseau horaire du groupe de paramètres de l’instance de base de données restaurée.
L'Internet Assigned Numbers Authority (IANA) publie de nouveaux fuseaux horaires sur [https://www.iana.org/time-zones](https://www.iana.org/time-zones) plusieurs fois par an. Chaque fois que RDS publie une nouvelle version de maintenance mineure de MySQL, elle est livrée avec les dernières données de fuseau horaire au moment de la publication. Lorsque vous utilisez les dernières versions de RDS for MySQL, vous disposez de données de fuseau horaire récentes provenant de RDS. Pour vous assurer que votre instance de base de données dispose de données de fuseau horaire récentes, nous vous recommandons de passer à une version supérieure du moteur de base de données. Vous pouvez également modifier manuellement les tables de fuseaux horaires dans les instances de base de données MariaDB. Pour ce faire, vous pouvez utiliser des commandes SQL ou exécuter l'[outil mysql\$1tzinfo\$1to\$1sql](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html) dans un client SQL. Après la mise à jour manuelle des données de fuseau horaire, redémarrez votre instance de base de données pour que la modification prenne effet. RDS ne modifie ni ne réinitialise les données de fuseau horaire des instances de base de données en cours d'exécution. Les nouvelles données de fuseau horaire ne sont installées que lorsque vous effectuez une mise à niveau de la version du moteur de base de données.
Vous pouvez définir votre fuseau horaire local avec l’une des valeurs suivantes.
| disponibilité | Fuseau horaire |
| --- | --- |
| Afrique | Afrique/Le Caire, Afrique/Casablanca, Afrique/Harare, Afrique/Monrovia, Afrique/Nairobi, Afrique/Tripoli, Afrique/Windhoek |
| Amérique | Amérique/Araguaina, Amérique/Asuncion, Amérique/Bogota, Amérique/Buenos\$1Aires, Amérique/Caracas, Amérique/Chihuahua, Amérique/Cuiaba, Amérique/Denver, Amérique/Fortaleza, Amérique/Guatemala, Amérique/Halifax, Amérique/Manaus, Amérique/Matamoros, Amérique/Monterrey, Amérique/Montevideo, Amérique/Phoenix, Amérique/Santiago, Amérique/Tijuana |
| Asie | Asie/Amman, Asie/Achgabat, Asie/Bagdad, Asie/Bakou, Asie/Bangkok, Asie/Beyrouth, Asie/Calcutta, Asie/Damas, Asie/Dhaka, Asie/Irkoutsk, Asie/Jérusalem, Asie/Kaboul, Asie/Karachi, Asie/Katmandou, Asie/Krasnoïarsk, Asie/Magadan, Asie/Muscat, Asie/Novosibirsk, Asie/Riyad, Asie/Séoul, Asie/Shanghai, Asie/Singapour, Asie/Taipei, Asie/Téhéran, Asie/Tokyo, Asie/Oulan\$1Bator, Asie/Vladivostok, Asie/Iakoutsk, Asie/Yerevan |
| Atlantique | Atlantique/Açores |
| Australie | Australie/Adelaide, Australie/Brisbane, Australie/Darwin, Australie/Hobart, Australie/Perth, Australie/Sydney |
| Brésil | Brésil/DeNoronha, Brésil/Est |
| Canada | Canada/Terre-Neuve, Canada/Saskatchewan, Canada/Yukon |
| Europe | Europe/Amsterdam, Europe/Athènes, Europe/Dublin, Europe/Helsinki, Europe/Istanbul, Europe/Kaliningrad, Europe/Moscou, Europe/Paris, Europe/Prague, Europe/Sarajevo |
| Pacifique | Pacifique/Auckland, Pacifique/Fidji, Pacifique/Guam, Pacifique/Honolulu, Pacifique/Samoa |
| ETATS-UNIS | États-Unis/Alaska, États-Unis/Centre, États-Unis/Indiana Est, États-Unis/Est, États-Unis/Pacifique |
| UTC | UTC |
# 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.
**Topics**
+ [
## Mot réservé InnoDB
](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbDatabaseName)
+ [
## Comportement de stockage plein pour Amazon RDS for MySQL
](#MySQL.Concepts.StorageFullBehavior)
+ [
## Taille de groupe de mémoires tampons InnoDB incohérente
](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbBufferPoolSize)
+ [
## L'optimisation de la fusion d'index renvoie des résultats incorrects
](#MySQL.Concepts.KnownIssuesAndLimitations.IndexMergeOptimization)
+ [
## Exceptions des paramètres MySQL pour les instances de base de données Amazon RDS
](#MySQL.Concepts.ParameterNotes)
+ [
## Limites de taille des fichiers MySQL dans Amazon RDS
](#MySQL.Concepts.Limits.FileSize)
+ [
## Plug-in MySQL Keyring non pris en charge
](#MySQL.Concepts.Limits.KeyRing)
+ [
## Ports personnalisés
](#MySQL.Concepts.KnownIssuesAndLimitations.CustomPorts)
+ [
## Limitations des procédures stockées MySQL
](#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures)
+ [
## Réplication basée sur GTID avec une instance source externe
](#MySQL.Concepts.KnownIssuesAndLimitations.GTID)
+ [
## Plugin d’authentification par défaut MySQL
](#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin)
+ [
## Remplacer innodb\$1buffer\$1pool\$1size
](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size)
+ [
## Mise à niveau de MySQL 5.7 vers MySQL 8.4
](#MySQL.Concepts.KnownIssuesAndLimitations.upgrade-8-4)
+ [
## Compression de page InnoDB
](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-page-compression)
## 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 :
+ Modifiez l'instance de base de données pour activer le dimensionnement automatique du stockage.
Pour plus d'informations sur le dimensionnement automatique du stockage, consultez [Gestion automatique de la capacité avec le dimensionnement automatique du stockage Amazon RDS](USER_PIOPS.Autoscaling.md).
+ Modifiez l'instance de base de données pour augmenter sa capacité de stockage.
Pour plus d'informations sur l'augmentation de la capacité de stockage, consultez [Augmentation de la capacité de stockage d'une instance de base de données](USER_PIOPS.ModifyingExisting.md).
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](Overview.DBInstance.Modifying.md).
## Taille de groupe 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 groupe 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 groupe 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 de détails sur ce bogue MySQL 5.7, consultez le [https://bugs.mysql.comfichier /bug.php ? id=79379 dans la documentation](https://bugs.mysql.com/bug.php?id=79379) 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](https://bugs.mysql.com/bug.php?id=72745) et [http://bugs.mysql.com/bug.php?id=68194](https://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.
```
1. SELECT * FROM table1
2. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
```
Dans ce cas, le moteur de recherche analysera les deux index. Néanmoins, en raison du bug, 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 [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
+ Mettez à niveau votre instance de base de données MySQL vers MySQL version 5.7 ou 8.0. Pour de plus amples informations, veuillez consulter [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
+ 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 :
```
1. SELECT * FROM table1
2. USE INDEX covering_index
3. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
```
Pour en savoir plus, consultez [Index merge optimization](https://dev.mysql.com/doc/refman/8.0/en/index-merge-optimization.html) (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\$1case\$1table\$1names
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, version 8.0.28 et versions 8.0 ultérieures, et version 8.4.
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 ou 8.4, 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\$1query\$1time
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 versions 8.0 et ultérieures, la taille de fichier maximale est de 16 Tio. Lorsque vous utilisez des file-per-table tablespaces, la taille de fichier maximale limite la taille d'une table InnoDB à 16 TiB. 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. Pour plus d’informations, consultez [Limites InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) dans la documentation 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 les [File-per-table espaces de table](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html) 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 plus d’informations, consultez [Partitionnement](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html) 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**
Le tablespace du dictionnaire de données est spécifique à MySQL 8.0 et versions ultérieures.
```
1. select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE)
2. /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES
3. 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.
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. 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 et ultérieures)**
+ Utilisez la commande SQL suivante pour déterminer si certaines de vos tables sont trop volumineuses et peuvent faire l’objet d’un partitionnement.
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. 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\$1file\$1per\$1table* 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\$1file\$1per\$1table* 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](USER_WorkingWithParamGroups.md).
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;
```
## 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\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) et [mysql.rds\$1kill\$1query](mysql-stored-proc-ending.md#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 prend en charge la réplication basée sur des identifiants de transaction globaux (GTIDs) depuis une instance MySQL externe vers une instance de base de données Amazon RDS for MySQL qui nécessite de définir GTID\$1PURGED lors de la configuration. Cependant, seules les versions 8.0.37 et ultérieures de RDS for MySQL prennent en charge cette fonctionnalité.
## Plugin d’authentification par défaut MySQL
RDS for MySQL version 8.0.34 et versions 8.0 ultérieures utilisent le plugin `mysql_native_password`. Vous ne pouvez pas modifier le paramètre `default_authentication_plugin`.
RDS for MySQL version 8.4 et versions ultérieures utilisent le plugin `caching_sha2_password` comme plugin d’authentification par défaut. Vous pouvez modifier le plugin d’authentification par défaut pour MySQL 8.4. Le plugin `mysql_native_password` fonctionne toujours avec MySQL 8.4, mais la prise en charge de ce plugin prend fin avec MySQL 8.4. Pour modifier le plugin d’authentification par défaut, créez un groupe de paramètres personnalisés et modifiez la valeur du paramètre `authentication_policy`. Pour de plus amples informations, veuillez consulter [Groupes de paramètres par défaut et personnalisés](parameter-groups-overview.md#parameter-groups-overview.custom).
## Remplacer innodb\$1buffer\$1pool\$1size
Dans le cas de classes d’instance de base de données de taille micro ou petite, la valeur par défaut du paramètre `innodb_buffer_pool_size` 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’instance 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 [Types d’instance Amazon RDS](https://aws.amazon.com/rds/instance-types/).
Si votre instance de base de données ne dispose que de 4 Go de mémoire, vous ne pouvez pas définir `innodb_buffer_pool_size` sur 8 Go, mais vous pouvez peut-être le 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 RDS la réduit aux limites suivantes :
+ Classes d’instance de base de données Micro : 256 Mo
+ Classes d’instance de base de données db.t4g.micro : 128 Mo
## Mise à niveau de MySQL 5.7 vers MySQL 8.4
Vous ne pouvez pas passer directement de MySQL 5.7 à MySQL 8.4. Vous devez d’abord passer de MySQL 5.7 à MySQL 8.0, puis de MySQL 8.0 à MySQL 8.4. Pour de plus amples informations, veuillez consulter [Mises à niveau des versions majeures pour RDS for MySQL](USER_UpgradeDBInstance.MySQL.Major.md).
## Compression de page InnoDB
La compression de page InnoDB ne fonctionne pas avec les instances de base de données Amazon RDS dont la taille de bloc du système de fichiers est de 16 Ko, car la taille de bloc du système de fichiers doit être inférieure à la taille de la page InnoDB. À compter de février 2024, toutes les instances de base de données nouvellement créées ont une taille de bloc de système de fichiers de 16 Ko, ce qui augmente le débit et réduit la consommation d’IOPS lors du vidage des pages.
# Référence des procédures stockées RDS pour MySQL
Ces rubriques décrivent les procédures stockées système disponibles pour les instances Amazon RDS exécutant le moteur de base de données MySQL. L'utilisateur principal doit exécuter ces procédures.
**Topics**
+ [
# Collecte et maintenance de l’historique global des statuts
](mysql-stored-proc-gsh.md)
+ [
# Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)
](mysql-stored-proc-replicating.md)
+ [
# Mettre fin à une session ou à une requête
](mysql-stored-proc-ending.md)
+ [
# Gestion des clusters actifs-actifs
](mysql-stored-proc-active-active-clusters.md)
+ [
# Gestion de la réplication multisource
](mysql-stored-proc-multi-source-replication.md)
+ [
# Répliquer des transactions à l'aide de GTIDs
](mysql-stored-proc-gtid.md)
+ [
# Rotation des journaux de requêtes
](mysql-stored-proc-logging.md)
+ [
# Configuration et affichage de la configuration du journal binaire
](mysql-stored-proc-configuring.md)
+ [
# Réchauffement du cache InnoDB
](mysql-stored-proc-warming.md)
# Collecte et maintenance de l’historique global des statuts
Amazon RDS fournit un ensemble de procédures qui prennent des instantanés des valeurs des variables d’état au fil du temps et les écrivent dans une table, ainsi que toutes les modifications intervenues depuis le dernier instantané. Cette infrastructure porte le nom d'historique global des statuts. Pour plus d'informations, consultez [Gestion de l’historique global des statuts de RDS for MySQL](Appendix.MySQL.CommonDBATasks.GoSH.md).
Les procédures stockées suivantes gèrent la manière dont l'historique global des statuts est collecté et conservé.
**Topics**
+ [
## mysql.rds\$1collect\$1global\$1status\$1history
](#mysql_rds_collect_global_status_history)
+ [
## mysql.rds\$1disable\$1gsh\$1collector
](#mysql_rds_disable_gsh_collector)
+ [
## mysql.rds\$1disable\$1gsh\$1rotation
](#mysql_rds_disable_gsh_rotation)
+ [
## mysql.rds\$1enable\$1gsh\$1collector
](#mysql_rds_enable_gsh_collector)
+ [
## mysql.rds\$1enable\$1gsh\$1rotation
](#mysql_rds_enable_gsh_rotation)
+ [
## mysql.rds\$1rotate\$1global\$1status\$1history
](#mysql_rds_rotate_global_status_history)
+ [
## mysql.rds\$1set\$1gsh\$1collector
](#mysql_rds_set_gsh_collector)
+ [
## mysql.rds\$1set\$1gsh\$1rotation
](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Prend un instantané sur demande pour l'historique global des statuts.
### Syntaxe
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Désactive les instantanés pris par l'historique global des statuts.
### Syntaxe
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
Désactive la rotation de la table `mysql.global_status_history`.
### Syntaxe
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Active l'historique global des statuts pour prendre des instantanés par défaut aux intervalles spécifiés par `rds_set_gsh_collector`.
### Syntaxe
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
Active la rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` aux intervalles spécifiés par `rds_set_gsh_rotation`.
### Syntaxe
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
Effectue une rotation du contenu de la table `mysql.global_status_history` en `mysql.global_status_history_old` à la demande.
### Syntaxe
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Spécifie l'intervalle, en minutes, entre les instantanés pris par l'historique global des statuts.
### Syntaxe
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### Paramètres
*intervalPeriod*
Intervalle, en minutes, entre les instantanés. La valeur par défaut est `5`.
## mysql.rds\$1set\$1gsh\$1rotation
Spécifie l’intervalle, en jours, entre deux rotations de la table `mysql.global_status_history`.
### Syntaxe
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### Paramètres
*intervalPeriod*
Intervalle, en jours, entre deux rotations de table. La valeur par défaut est `7`.
# Configuration, démarrage et arrêt de la réplication des journaux binaires (binlog)
Les procédures stockées suivantes contrôlent la façon dont les transactions sont répliquées à partir d’une base de données externe dans RDS for MySQL, ou à partir de RDS for MySQL vers une base de données externe.
Lorsque vous utilisez ces procédures stockées pour gérer la réplication avec un utilisateur de réplication configuré avec `caching_sha2_password`, vous devez configurer le protocole TLS en spécifiant `SOURCE_SSL=1`. `caching_sha2_password` est le plugin d’authentification par défaut pour RDS for MySQL 8.4. Pour plus d’informations, consultez [Chiffrement avec SSL/TLS](mysql-ssl-connections.md).
Pour en savoir plus sur la configuration, l’utilisation et la gestion de réplicas en lecture, consultez [Utilisation de réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.md).
**Topics**
+ [
##
](#mysql_rds_next_master_log)
+ [
## mysql.rds\$1next\$1source\$1log (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_next_source_log)
+ [
## mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
](#mysql_rds_reset_external_master)
+ [
## mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_reset_external_source)
+ [
## mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
](#mysql_rds_set_external_master)
+ [
## mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_set_external_source)
+ [
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.0 et antérieures)
](#mysql_rds_set_external_master_with_auto_position)
+ [
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_set_external_source_with_auto_position)
+ [
## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
](#mysql_rds_set_external_master_with_delay)
+ [
## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_set_external_source_with_delay)
+ [
## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged
](#mysql_rds_set_external_source_gtid_purged)
+ [
##
](#mysql_rds_set_master_auto_position)
+ [
## mysql.rds\$1set\$1source\$1auto\$1position (RDS for MySQL, versions majeures 8.4 et ultérieures)
](#mysql_rds_set_source_auto_position)
+ [
## mysql.rds\$1set\$1source\$1delay
](#mysql_rds_set_source_delay)
+ [
## mysql.rds\$1skip\$1repl\$1error
](#mysql_rds_skip_repl_error)
+ [
## mysql.rds\$1start\$1replication
](#mysql_rds_start_replication)
+ [
##
](#mysql_rds_start_replication_until)
+ [
## mysql.rds\$1stop\$1replication
](#mysql_rds_stop_replication)
##
Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture.
### Syntaxe
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### Parameters
*curr\$1master\$1log*
Index du fichier journal maître actif. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal maître actif, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Master_Log_File`.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_next_master_log`.
**Avertissement**
Appelez `mysql.rds_next_master_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236.
L’appel de `mysql.rds_next_master_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise. Vous pouvez réduire la probabilité que cela se produise en définissant les paramètres d’instance source `sync_binlog` et `innodb_support_xa` sur `1`, même si cela peut compromettre les performances. Pour plus d'informations, consultez [Résolution d'un problème de réplica en lecture MySQL](USER_ReadRepl.Troubleshooting.md).
### Exemples
Supposons que la réplication échoue sur un réplica en lecture RDS pour MySQL. L’exécution de `SHOW REPLICA STATUS\G` sur le réplica en lecture renvoie le résultat suivant :
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
Le champ `Last_IO_Errno` montre que l’instance reçoit une erreur 1236 d’I/O. Le champ `Master_Log_File` montre que le nom du fichier est `mysql-bin-changelog.012345`, ce qui signifie que l’index du fichier journal est `12345`. Pour résoudre l’erreur, vous pouvez appeler `mysql.rds_next_master_log` avec le paramètre suivant :
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (RDS for MySQL, versions majeures 8.4 et ultérieures)
Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source. Utilisez cette procédure uniquement si vous recevez l' I/O erreur de réplication 1236 sur une réplique en lecture.
### Syntaxe
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### Parameters
*curr\$1source\$1log*
Index du fichier journal source actuel. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal actuel, exécutez la commande `SHOW REPLICA STATUS` et affichez le champ `Source_Log_File`.
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_next_source_log`.
**Avertissement**
Appelez `mysql.rds_next_source_log` uniquement si la réplication échoue après le basculement d'une instance de base de données multi-AZ qui est la source de réplication et si le `Last_IO_Errno` champ de `SHOW REPLICA STATUS` signale l' I/O erreur 1236.
L’appel de `mysql.rds_next_source_log` peut se traduire par une perte de données dans le réplica en lecture si les transactions de l’instance source n’ont pas été écrites dans le journal binaire sur disque avant que l’événement de basculement se produise. Vous pouvez réduire la probabilité que cela se produise en définissant les paramètres d’instance source `sync_binlog` et `innodb_support_xa` sur `1`, même si cela peut compromettre les performances. Pour plus d’informations, consultez [Résolution d'un problème de réplica en lecture MySQL](USER_ReadRepl.Troubleshooting.md).
### Exemples
Supposons que la réplication échoue sur un réplica en lecture RDS pour MySQL. L’exécution de `SHOW REPLICA STATUS\G` sur le réplica en lecture renvoie le résultat suivant :
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
Le champ `Last_IO_Errno` montre que l’instance reçoit une erreur 1236 d’I/O. Le champ `Source_Log_File` montre que le nom du fichier est `mysql-bin-changelog.012345`, ce qui signifie que l’index du fichier journal est `12345`. Pour résoudre l’erreur, vous pouvez appeler `mysql.rds_next_source_log` avec le paramètre suivant :
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
Reconfigure une instance de base de données RDS for MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_reset_external_master;
```
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_reset_external_master`. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Pour plus d’informations sur l’utilisation de la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
## mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)
Reconfigure une instance de base de données RDS for MySQL comme n’étant plus un réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_reset_external_source;
```
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_reset_external_source`. Cette procédure doit être exécutée sur l’instance de base de données MySQL à supprimer comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS.
Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md). Pour plus d’informations sur l’utilisation de la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
## mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Note**
Vous pouvez utiliser la procédure stockée [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_set_external_master_with_delay) pour configurer une instance de base de données source externe et une réplication différée.
### Syntaxe
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `MASTER_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_master`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Avant d’exécuter `mysql.rds_set_external_master`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs `replication_user_name` et `replication_user_password` qui indiquent un utilisateur de réplication possédant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple.
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL.
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Après avoir appelé `mysql.rds_set_external_master` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_reset_external_master) pour supprimer la configuration du réplica en lecture.
Quand la procédure `mysql.rds_set_external_master` est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
### Exemples
Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `SOURCE_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_external_source`. Cette procédure doit être exécutée sur l’instance de base de données RDS for MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Avant d’exécuter `mysql.rds_set_external_source`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL en cours d’exécution en dehors de Amazon RDS, vous devez spécifier des valeurs `replication_user_name` et `replication_user_password` qui indiquent un utilisateur de réplication possédant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL. De plus, importez le certificat de l’autorité de certification, le certificat du client et la clé du client dans l’instance de base de données ou le cluster de bases de données à l’aide de la procédure [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html).
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Après avoir appelé `mysql.rds_set_external_source` pour configurer une instance de base de données RDS for MySQL comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_reset_external_source) pour supprimer la configuration du réplica en lecture.
Quand la procédure `mysql.rds_set_external_source` est appelée, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
### Exemples
Lors d’une exécution sur une instance de base de données RDS for MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS.
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.0 et antérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS. Cette procédure configure également la réplication différée et la réplication en fonction des identificateurs de transaction globaux ()GTIDs.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
, delay
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `MASTER_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_master_with_auto_position`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Cette procédure est prise en charge pour toutes les versions de RDS for MySQL 5.7, et RDS for MySQL 8.0.26 et les versions 8.0 ultérieures.
Avant d’exécuter `mysql.rds_set_external_master_with_auto_position`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL s’exécutant en dehors d’Amazon RDS, vous devez spécifier des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Pour plus d’informations, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Avant d’appeler `mysql.rds_set_external_master_with_auto_position`, assurez-vous d’appeler [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) pour définir la variable système `gtid_purged` avec une plage GTID spécifiée à partir d’une source externe.
Après avoir appelé `mysql.rds_set_external_master_with_auto_position` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_reset_external_master) pour supprimer la configuration du réplica en lecture.
Lorsque vous appelez `mysql.rds_set_external_master_with_auto_position`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
Pour la reprise après sinistre, vous pouvez utiliser cette procédure avec la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_external_master_with_auto_position`. Une fois que la procédure `mysql.rds_start_replication_until_gtid` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
### Exemples
Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. Il définit le délai de réplication minimal à une heure (soit 3 600 secondes) sur l’instance de base de données MySQL. Une modification provenant de l’instance de base de données source MySQL exécutée à l’extérieur d’Amazon RDS n’est pas appliquée dans le réplica en lecture de l’instance de base de données MySQL pendant au moins une heure.
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user',
'SomePassW0rd',
1,
3600);
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.4 et ultérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS. Cette procédure configure également la réplication différée et la réplication en fonction des identificateurs de transaction globaux ()GTIDs.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
, delay
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS pour devenir l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `SOURCE_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_external_source_with_auto_position`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Avant d’exécuter `mysql.rds_set_external_source_with_auto_position`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL s’exécutant en dehors d’Amazon RDS, vous devez spécifier des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Pour plus d’informations, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Avant d’appeler `mysql.rds_set_external_source_with_auto_position`, assurez-vous d’appeler [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) pour définir la variable système `gtid_purged` avec une plage GTID spécifiée à partir d’une source externe.
Après avoir appelé `mysql.rds_set_external_source_with_auto_position` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_reset_external_source) pour supprimer la configuration du réplica en lecture.
Lorsque vous appelez `mysql.rds_set_external_source_with_auto_position`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
Pour la reprise après sinistre, vous pouvez utiliser cette procédure avec la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_external_source_with_auto_position`. Une fois que la procédure `mysql.rds_start_replication_until_gtid` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
### Exemples
Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. Il définit le délai de réplication minimal à une heure (soit 3 600 secondes) sur l’instance de base de données MySQL. Une modification provenant de l’instance de base de données source MySQL exécutée à l’extérieur d’Amazon RDS n’est pas appliquée dans le réplica en lecture de l’instance de base de données MySQL pendant au moins une heure.
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user',
'SomePassW0rd',
1,
3600);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS et configure une réplication retardée.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_master_with_delay(
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
, delay
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et qui deviendra l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port SSH qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Le nom du journal binaire sur l’instance de base de données source contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `MASTER_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_master_with_delay`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Avant d’exécuter `mysql.rds_set_external_master_with_delay`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL s’exécutant en dehors d’Amazon RDS, vous devez spécifier des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Pour plus d’informations, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Après avoir appelé `mysql.rds_set_external_master_with_delay` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_reset_external_master) pour supprimer la configuration du réplica en lecture.
Lorsque vous appelez `mysql.rds_set_external_master_with_delay`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
Pour la reprise après sinistre, vous pouvez utiliser cette procédure avec la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_external_master_with_delay`. Une fois que la procédure `mysql.rds_start_replication_until` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
La procédure `mysql.rds_set_external_master_with_delay` est disponible dans les versions de RDS for MySQL suivantes :
+ MySQL 8.0.26 et versions 8.0 ultérieures
+ Toutes les versions 5.7
### Exemples
Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. Il définit le délai de réplication minimal à une heure (soit 3 600 secondes) sur l’instance de base de données MySQL. Une modification provenant de l’instance de base de données source MySQL exécutée à l’extérieur d’Amazon RDS n’est pas appliquée dans le réplica en lecture de l’instance de base de données MySQL pendant au moins une heure.
```
call mysql.rds_set_external_master_with_delay(
'Externaldb.some.com',
3306,
'repl_user',
'SomePassW0rd',
'mysql-bin-changelog.000777',
120,
1,
3600);
```
## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)
Configure une instance de base de données RDS for MySQL comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur de Amazon RDS et configure une réplication retardée.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source_with_delay (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
, delay
);
```
### Parameters
*host\$1name*
Nom d’hôte ou adresse IP de l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et qui deviendra l’instance de base de données source.
*host\$1port*
Port utilisé par l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS et à configurer comme instance de base de données source. Si votre configuration réseau inclut une réplication de port SSH qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance MySQL s’exécutant à l’extérieur d’Amazon RDS. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance externe.
*replication\$1user\$1password*
Mot de passe de l’ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Le nom du journal binaire sur l’instance de base de données source contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW MASTER STATUS` sur l’instance de base de données source.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d’utiliser le chiffrement SSL, et la valeur 0 de ne pas l’utiliser. La valeur par défaut est 0.
L’option `SOURCE_SSL_VERIFY_SERVER_CERT` n’est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_external_source_with_delay`. Cette procédure doit être exécutée sur l’instance de base de données MySQL qui doit être configurée comme réplica en lecture d’une instance MySQL s’exécutant en dehors d’Amazon RDS.
Avant d’exécuter `mysql.rds_set_external_source_with_delay`, vous devez configurer l’instance de MySQL s’exécutant en dehors de Amazon RDS comme instance de base de données source. Pour vous connecter à l’instance MySQL s’exécutant en dehors d’Amazon RDS, vous devez spécifier des valeurs pour `replication_user_name` et `replication_user_password`. Ces valeurs doivent indiquer un utilisateur de réplication disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance externe de MySQL.
**Pour configurer une instance externe de MySQL en tant qu’instance de base de données source**
1. A l’aide du client MySQL de votre choix, connectez-vous à l’instance externe de MySQL et créez un compte d’utilisateur à utiliser pour la réplication. Voici un exemple de.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. Sur l’instance externe de MySQL, accordez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur `'repl_user'` de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
Pour plus d’informations, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Note**
Nous vous conseillons d’utiliser des réplicas en lecture pour gérer la réplication entre deux instances de base de données Amazon RDS dès que possible. Dans ce cas, nous vous conseillons d’utiliser seulement cette procédure et d’autres procédures stockées liées à la réplication. Ces pratiques permettent d’obtenir des topologies de réplication plus complexes entre des instances de base de données Amazon RDS. Nous proposons ces procédures stockées avant tout pour permettre la réplication avec les instances MySQL s’exécutant en dehors d’Amazon RDS. Pour plus d’informations sur la gestion de la réplication entre les instances de base de données Amazon RDS, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Après avoir appelé `mysql.rds_set_external_source_with_delay` pour configurer une instance de base de données Amazon RDS comme réplica en lecture, vous pouvez appeler [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture pour démarrer le processus de réplication. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_reset_external_source) pour supprimer la configuration du réplica en lecture.
Lorsque vous appelez `mysql.rds_set_external_source_with_delay`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set master` dans les tables `mysql.rds_history` et `mysql.rds_replication_status`.
Pour la reprise après sinistre, vous pouvez utiliser cette procédure avec la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_external_source_with_delay`. Une fois que la procédure `mysql.rds_start_replication_until` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
### Exemples
Lors d’une exécution sur une instance de base de données MySQL, l’exemple suivant configure l’instance de base de données comme réplica en lecture d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS. Il définit le délai de réplication minimal à une heure (soit 3 600 secondes) sur l’instance de base de données MySQL. Une modification provenant de l’instance de base de données source MySQL exécutée à l’extérieur d’Amazon RDS n’est pas appliquée dans le réplica en lecture de l’instance de base de données MySQL pendant au moins une heure.
```
call mysql.rds_set_external_source_with_delay(
'Externaldb.some.com',
3306,
'repl_user',
'SomePassW0rd',
'mysql-bin-changelog.000777',
120,
1,
3600);
```
## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged
Définit la variable système [gtid\$1purged](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_purged) avec une plage GTID spécifiée à partir d’une source externe. La valeur `gtid_purged` est requise pour configurer la réplication GTID afin de reprendre la réplication à l’aide du positionnement automatique.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l’activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source_gtid_purged(
server_uuid
, start_pos
, end_pos
);
```
### Parameters
*server\$1uuid*
L’identifiant universel unique (UUID) du serveur externe à partir duquel la plage GTID est importée.
*start\$1pos*
La position de départ de la plage GTID à définir.
*end\$1pos*
La position de fin de la plage GTID à définir.
### Notes d’utilisation
La procédure `mysql.rds_set_external_source_gtid_purged` est uniquement disponible avec MySQL 8.0.37 et les versions 8.0 ultérieures.
Appelez `mysql.rds_set_external_source_gtid_purged` avant d’appeler [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_set_external_master_with_auto_position), [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_set_external_source_with_auto_position) ou [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_set_external_source_with_auto_position_for_channel).
Avant d’appeler `mysql.rds_set_external_source_gtid_purged`, assurez-vous d’arrêter tous les canaux de réplication actifs pour la base de données. Pour vérifier l’état d’un canal, utilisez l’instruction MySQL `SHOW REPLICA STATUS`. Pour arrêter la réplication sur un canal, appelez [mysql.rds\$1stop\$1replication\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_stop_replication_for_channel).
La plage GTID que vous spécifiez doit être un sur-ensemble de la valeur existante `GTID_PURGED`. Cette procédure stockée vérifie les valeurs suivantes avant de définir la valeur `GTID_PURGED` :
+ Le `server_uuid` est valide.
+ La valeur `start_pos` est supérieure à `0` et inférieure à la valeur `end_pos`.
+ La valeur `end_pos` est supérieure ou égale à la valeur `start_pos`.
Si le GTID défini sur votre serveur externe contient plusieurs plages de valeurs, il est recommandé d’appeler la procédure plusieurs fois, avec différentes valeurs de GTID.
Lorsque vous appelez `mysql.rds_set_external_source_gtid_purged`, Amazon RDS enregistre l’heure, l’utilisateur et une action `set gtid_purged` dans la table `mysql.rds_history`.
Si vous ne définissez pas la valeur `gtid_purged` appropriée pour la sauvegarde que vous utilisez pour la réplication, certaines transactions peuvent être manquantes ou dupliquées au cours du processus de réplication. Effectuez les étapes suivantes pour définir la valeur `gtid_purged` appropriée.
**Pour définir la valeur gtid\$1purged sur le réplica**
1. Identifiez le moment précis ou le fichier de sauvegarde à utiliser comme point de départ de la réplication. Il peut s’agir d’une sauvegarde logique (un fichier mysqldump) ou physique (un instantané Amazon RDS).
1. Déterminez la valeur `gtid_executed`. Cette valeur représente l'ensemble de tous ceux GTIDs qui ont été validés sur le serveur. Pour obtenir cette valeur, effectuez l’une des actions suivantes sur l’instance source :
+ Exécutez l’instruction SQL `SELECT @@GLOBAL.GTID_EXECUTED;` au moment de la sauvegarde.
+ Si des options associées sont incluses dans l’utilitaire de sauvegarde correspondant, extrayez la valeur du fichier de sauvegarde. Pour plus d'informations, consultez l'[set-gtid-purged](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html#option_mysqldump_set-gtid-purged)option dans la documentation MySQL.
1. Déterminez la valeur `gtid_purged` à utiliser pour l’appel à `mysql.rds_set_external_source_gtid_purged`. La `gtid_purged` valeur doit inclure tous ceux GTIDs qui ont été exécutés sur l'instance source et qui ne sont plus nécessaires pour la réplication. Cette valeur `gtid_purged` doit donc être un sous-ensemble de la valeur `gtid_executed` récupérée à l’étape précédente.
Pour déterminer la `gtid_purged` valeur, identifiez ceux GTIDs qui ne sont pas inclus dans la sauvegarde et qui ne sont plus nécessaires pour la réplication. Vous pouvez le faire en analysant les journaux binaires ou en utilisant un outil tel que mysqlbinlog pour trouver ceux GTIDs qui ont été purgés des journaux binaires.
Sinon, si vous disposez d’une sauvegarde cohérente qui inclut tous les journaux binaires jusqu’au point de sauvegarde, vous pouvez attribuer à la valeur `gtid_purged` la même valeur que la valeur `gtid_executed` à ce moment-là.
1. Après avoir déterminé la valeur `gtid_purged` appropriée cohérente avec votre sauvegarde, appelez la procédure `mysql.rds_set_external_source_gtid_purged` stockée sur votre instance de base de données RDS for MySQL pour définir la valeur.
### Exemples
Lorsqu’il est exécuté sur une instance de base de données MySQL, l’exemple suivant définit la plage GTID d’un serveur MySQL externe avec l’UUID `12345678-abcd-1234-efgh-123456789abc`, une position de départ de `1` et une position de fin de `100`. La valeur GTID résultante est définie sur `+12345678-abcd-1234-efgh-123456789abc:1-100`.
```
CALL mysql.rds_set_external_source_gtid_purged('12345678-abcd-1234-efgh-123456789abc', 1, 100);
```
##
Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs).
### Syntaxe
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### Parameters
*auto\$1position\$1mode*
Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux :
+ `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`.
+ `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_master_auto_position`.
Cette procédure est prise en charge pour toutes les versions de RDS for MySQL 5.7, et RDS for MySQL 8.0.26 et les versions 8.0 ultérieures.
## mysql.rds\$1set\$1source\$1auto\$1position (RDS for MySQL, versions majeures 8.4 et ultérieures)
Définit le mode de réplication en fonction des positions du fichier journal binaire ou des identificateurs de transaction globaux (GTIDs).
### Syntaxe
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### Parameters
*auto\$1position\$1mode*
Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux :
+ `0` : utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`.
+ `1` : utiliser la méthode de réplication basée sur les identifiants de transaction globaux.
### Notes d’utilisation
L’utilisateur administratif doit exécuter la procédure `mysql.rds_set_source_auto_position`.
## mysql.rds\$1set\$1source\$1delay
Définit le nombre minimum de secondes pour retarder la réplication de l’instance de base de données source vers le réplica en lecture actuel. Utilisez cette procédure lorsque vous êtes connecté à un réplica en lecture afin de retarder la réplication à partir de l’instance de base de données source.
### Syntaxe
```
CALL mysql.rds_set_source_delay(
delay
);
```
### Parameters
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_source_delay`.
Pour la reprise après sinistre, vous pouvez utiliser cette procédure avec la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_source_delay`. Une fois que la procédure `mysql.rds_start_replication_until` ou `mysql.rds_start_replication_until_gtid` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
La procédure `mysql.rds_set_source_delay` est disponible dans les versions de RDS for MySQL suivantes :
+ Toutes les versions RDS for MySQL 8.4
+ MySQL 8.0.26 et versions 8.0 ultérieures
+ Toutes les versions 5.7
### Exemples
Pour retarder la réplication à partir de l’instance de base de données source vers le réplica en lecture actuel pendant au moins un heure (3 600 secondes), vous pouvez appeler `mysql.rds_set_source_delay` avec le paramètre suivant :
```
CALL mysql.rds_set_source_delay(3600);
```
## mysql.rds\$1skip\$1repl\$1error
Ignore et supprime une erreur de réplication sur un réplica en lecture d’une base de données MySQL.
### Syntaxe
```
CALL mysql.rds_skip_repl_error;
```
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_repl_error` sur un réplica en lecture. Pour plus d’informations sur cette procédure, consultez [Appel de la procédure mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure).
Pour déterminer s’il y a des erreurs, exécutez la commande MySQL `SHOW REPLICA STATUS\G`. Si une erreur de réplication n’est pas critique, vous pouvez exécuter `mysql.rds_skip_repl_error` pour ignorer l’erreur. S’il y a plusieurs erreurs, `mysql.rds_skip_repl_error` supprime la première erreur, puis avertit qu’il y a d’autres erreurs. Vous pouvez alors utiliser `SHOW REPLICA STATUS\G` pour déterminer l’action appropriée pour l’erreur suivante. Pour obtenir des informations sur les valeurs renvoyées, consultez [Instruction SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) dans la documentation sur MySQL.
Pour plus d’informations sur le traitement des erreurs de réplication avec Amazon RDS, consultez [Résolution d'un problème de réplica en lecture MySQL](USER_ReadRepl.Troubleshooting.md).
#### Erreur d’arrêt de réplication
Lorsque vous appelez la procédure `mysql.rds_skip_repl_error`, un message d’erreur peut s’afficher pour indiquer que le réplica a rencontré une erreur ou est désactivé.
Ce message d’erreur s’affiche si vous exécutez la procédure sur l’instance principale plutôt que sur le réplica en lecture. Vous devez exécuter cette procédure sur le réplica en lecture pour que la procédure fonctionne.
Ce message d’erreur peut également s’afficher si vous exécutez la procédure sur le réplica en lecture, mais que la réplication ne peut pas être redémarrée correctement.
Si vous avez besoin d’ignorer un grand nombre d’erreurs, le retard de réplication peut augmenter et dépasser la période de rétention par défaut pour les fichiers journaux binaires (binlog). Dans ce cas, vous pouvez rencontrer une erreur irrécupérable due à des fichiers journaux binaires purgés avant d’avoir été réutilisés sur le réplica en lecture. Cette purge entraîne l'arrêt de la réplication et vous ne pouvez plus appeler la commande `mysql.rds_skip_repl_error` pour ignorer les erreurs de réplication.
Vous pouvez atténuer ce problème en augmentant le nombre d’heures pendant lequel les fichiers journaux binaires sont conservés sur votre instance de base de données source. Une fois que vous avez augmenté le temps de rétention de journaux binaires, vous pouvez redémarrer la réplication et appeler la commande `mysql.rds_skip_repl_error` en fonction des besoins.
Pour définir la période de rétention des journaux binaires, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) et spécifiez un paramètre de configuration `'binlog retention hours'`, ainsi que le nombre d’heures pendant lequel conserver les fichiers journaux binaires sur le cluster de bases de données. L’exemple suivant définit la période de rétention des fichiers journaux binaires à 48 heures.
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Lance la réplication à partir d’une instance de base de données RDS for MySQL.
**Note**
Vous pouvez utiliser la procédure stockée [](#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) pour lancer la réplication à partir d’une instance de base de données RDS for MySQL et arrêter la réplication à la position spécifiée dans le fichier journal binaire.
### Syntaxe
```
CALL mysql.rds_start_replication;
```
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication`.
Pour importer des données à partir d’une instance de MySQL externe à Amazon RDS, appelez `mysql.rds_start_replication` sur le réplica en lecture pour démarrer le processus de réplication après avoir appelé [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_set_external_master)ou [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_set_external_source) pour créer la configuration de réplication. Pour plus d’informations, consultez [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Pour exporter des données vers une instance de MySQL extérieure à Amazon RDS, appelez `mysql.rds_start_replication` et `mysql.rds_stop_replication` sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, consultez [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Vous pouvez aussi appeler `mysql.rds_start_replication` sur le réplica en lecture pour redémarrer un processus de réplication que vous avez précédemment arrêté en appelant `mysql.rds_stop_replication`. Pour de plus amples informations, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
##
Lance la réplication à partir d’une instance de base de données RDS for MySQL et arrête la réplication à la position spécifiée dans le fichier journal binaire.
### Syntaxe
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### Parameters
*replication\$1log\$1file*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*replication\$1stop\$1point *
Position dans le journal binaire `replication_log_file` à laquelle la réplication s’arrêtera.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until`.
La procédure `mysql.rds_start_replication_until` est disponible dans les versions de RDS for MySQL suivantes :
+ Toutes les versions RDS for MySQL 8.4
+ MySQL 8.0.26 et versions 8.0 ultérieures
+ Toutes les versions 5.7
Vous pouvez utiliser cette procédure avec la réplication retardée pour la reprise après sinistre. Si vous avez configuré la réplication retardée, vous pouvez utiliser cette procédure pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre. Une fois que cette procédure a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Vous pouvez configurer la réplication retardée en utilisant les procédures stockées suivantes :
+ [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](#mysql_rds_set_external_master_with_delay)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)](#mysql_rds_set_external_source_with_delay)
+ [mysql.rds\$1set\$1source\$1delay](#mysql_rds_set_source_delay)
Le nom de fichier spécifié pour le paramètre `replication_log_file` doit correspondre au nom du fichier binlog de l’instance de base de données source.
Lorsque le paramètre `replication_stop_point` spécifie une position d’arrêt survenant dans le passé, la réplication est arrêtée immédiatement.
### Exemples
L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position `120` dans le fichier journal binaire `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
Arrête la réplication à partir d’une instance de base de données MySQL.
### Syntaxe
```
CALL mysql.rds_stop_replication;
```
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_stop_replication`.
Si vous configurez la réplication pour importer des données à partir d’une instance de MySQL s’exécutant à l’extérieur d’Amazon RDS, vous appelez `mysql.rds_stop_replication` sur le réplica en lecture pour arrêter le processus de réplication après que l’importation soit terminée. Pour plus d’informations, consultez [Restauration d’une sauvegarde dans une instance de base de données Amazon RDS for MySQL](MySQL.Procedural.Importing.md).
Si vous configurez la réplication pour exporter les données vers une instance de MySQL extérieure à Amazon RDS, vous appelez `mysql.rds_start_replication` et `mysql.rds_stop_replication` sur le réplica en lecture pour contrôler certaines actions de réplication, telles que la purge des journaux binaires. Pour plus d’informations, consultez [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Vous pouvez aussi utiliser `mysql.rds_stop_replication` pour arrêter la réplication entre deux instances de base de données Amazon RDS. Vous arrêtez généralement la réplication pour exécuter une longue opération sur le réplica en lecture, comme la création d’un index volumineux sur le réplica en lecture. Vous pouvez redémarrer tout processus de réplication que vous avez arrêté en appelant [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sur le réplica en lecture. Pour plus d’informations, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
# Mettre fin à une session ou à une requête
Les procédures stockées suivantes mettent fin à une session ou à une requête.
**Topics**
+ [
## mysql.rds\$1kill
](#mysql_rds_kill)
+ [
## mysql.rds\$1kill\$1query
](#mysql_rds_kill_query)
## mysql.rds\$1kill
Termine une connexion au serveur MySQL.
### Syntaxe
```
CALL mysql.rds_kill(processID);
```
### Paramètres
*processID*
Identité du thread de connexion à terminer.
### Notes d'utilisation
Chaque connexion au serveur MySQL s'exécute dans un thread distinct. Pour terminer une connexion, utilisez la procédure `mysql.rds_kill` et transmettez-lui l'ID de thread de cette connexion. Pour obtenir l'ID de thread, utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html).
Pour plus d'informations sur les limites, consultez [Limitations des procédures stockées MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures).
### Exemples
L'exemple suivant termine une connexion avec l'ID de thread 4243 :
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
Termine une requête s'exécutant sur le serveur MySQL.
### Syntaxe
```
CALL mysql.rds_kill_query(processID);
```
### Paramètres
*processID*
Identité du processus ou du thread qui exécute la requête à terminer.
### Notes d’utilisation
Pour arrêter une requête en cours d'exécution sur le serveur MySQL, utilisez la procédure `mysql_rds_kill_query` et transmettez l'ID de connexion du thread qui exécute la requête. La procédure met alors fin à la connexion.
Pour obtenir l'ID, interrogez la table MySQL [INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) ou utilisez la commande MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). La valeur figurant dans la colonne ID de `SHOW PROCESSLIST` ou `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` est le *processID*.
Pour plus d'informations sur les limites, consultez [Limitations des procédures stockées MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures).
### Exemples
L'exemple suivant arrête une requête dont l'ID de thread de requête est 230040 :
```
CALL mysql.rds_kill_query(230040);
```
# Gestion des clusters actifs-actifs
Les procédures stockées suivantes permettent de configurer et de gérer les clusters actifs-actifs RDS for MySQL. Pour plus d’informations, consultez [Configuration de clusters actifs-actifs pour RDS for MySQL](mysql-active-active-clusters.md).
Ces procédures stockées ne sont disponibles qu’avec les instances de base de données RDS for MySQL exécutant les versions suivantes :
+ Toutes les versions 8.4 de MySQL
+ MySQL 8.0.35 et versions mineures ultérieures
**Topics**
+ [
## mysql.rds\$1group\$1replication\$1advance\$1gtid
](#mysql_rds_group_replication_advance_gtid)
+ [
## mysql.rds\$1group\$1replication\$1create\$1user
](#mysql_rds_group_replication_create_user)
+ [
## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel
](#mysql_rds_group_replication_set_recovery_channel)
+ [
## mysql.rds\$1group\$1replication\$1start
](#mysql_rds_group_replication_start)
+ [
## mysql.rds\$1group\$1replication\$1stop
](#mysql_rds_group_replication_stop)
## mysql.rds\$1group\$1replication\$1advance\$1gtid
Crée des GTID d’espace réservé sur l’instance de base de données actuelle.
### Syntaxe
```
CALL mysql.rds_group_replication_advance_gtid(
begin_id
, end_id
, server_uuid
);
```
### Paramètres
*begin\$1id*
L’ID de transaction de départ à créer.
*end\$1id*
L’ID de transaction de fin à créer.
*begin\$1id*
Le `group_replication_group_name` de transaction à créer. Le `group_replication_group_name` est spécifié sous forme d’UUID dans le groupe de paramètres de base de données associé à l’instance de base de données.
### Notes d’utilisation
Dans un cluster actif-actif, pour qu’une instance de base de données rejoigne un groupe, toutes les transactions GTID exécutées sur la nouvelle instance de base de données doivent exister sur les autres membres du cluster. Dans des cas inhabituels, une nouvelle instance de base de données peut contenir davantage de transactions lorsque les transactions sont exécutées avant de joindre l’instance au groupe. Dans ce cas, vous ne pouvez supprimer aucune transaction existante, mais vous pouvez utiliser cette procédure pour créer les GTID d’espace réservé correspondants sur les autres instances de base de données du groupe. Avant cela, vérifiez que les transactions *n’affectent pas les données répliquées*.
Lorsque vous appelez cette procédure, les transactions GTID de `server_uuid:begin_id-end_id` sont créées avec un contenu vide. Pour éviter les problèmes de réplication, n’utilisez pas cette procédure dans d’autres conditions.
**Important**
Évitez d’appeler cette procédure lorsque le cluster actif-actif fonctionne normalement. N’appelez cette procédure que si vous comprenez les conséquences possibles des transactions que vous créez. L’appel de cette procédure peut entraîner des données incohérentes.
### exemple
L’exemple suivant crée des GTID d’espace réservé sur l’instance de base de données actuelle :
```
CALL mysql.rds_group_replication_advance_gtid(5, 6, '11111111-2222-3333-4444-555555555555');
```
## mysql.rds\$1group\$1replication\$1create\$1user
Crée l’utilisateur de réplication `rdsgrprepladmin` pour la réplication de groupe sur l’instance de base de données.
### Syntaxe
```
CALL mysql.rds_group_replication_create_user(
replication_user_password
);
```
### Paramètres
*replication\$1user\$1password*
Mot de passe de l’utilisateur de réplication `rdsgrprepladmin`.
### Notes d’utilisation
+ Le mot de passe de l’utilisateur de réplication `rdsgrprepladmin` doit être le même sur toutes les instances de base de données d’un cluster actif-actif.
+ Le nom d’utilisateur `rdsgrprepladmin` est réservé aux connexions de réplication de groupe. Aucun autre utilisateur, y compris l’utilisateur principal, ne peut avoir ce nom d’utilisateur.
### exemple
L’exemple suivant crée l’utilisateur de réplication `rdsgrprepladmin` pour la réplication de groupe sur l’instance de base de données :
```
CALL mysql.rds_group_replication_create_user('password');
```
## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel
Définit le canal `group_replication_recovery` d’un cluster actif-actif. La procédure utilise l’utilisateur réservé `rdsgrprepladmin` pour configurer le canal.
### Syntaxe
```
CALL mysql.rds_group_replication_set_recovery_channel(
replication_user_password);
```
### Paramètres
*replication\$1user\$1password*
Mot de passe de l’utilisateur de réplication `rdsgrprepladmin`.
### Notes d’utilisation
Le mot de passe de l’utilisateur de réplication `rdsgrprepladmin` doit être le même sur toutes les instances de base de données d’un cluster actif-actif. Un appel au `mysql.rds_group_replication_create_user` permet de spécifier le mot de passe.
### exemple
L’exemple suivant définit le canal `group_replication_recovery` d’un cluster actif-actif.
```
CALL mysql.rds_group_replication_set_recovery_channel('password');
```
## mysql.rds\$1group\$1replication\$1start
Démarre la réplication de groupe sur l’instance de base de données actuelle.
### Syntaxe
```
CALL mysql.rds_group_replication_start(
bootstrap
);
```
### Paramètres
*bootstrap*
Valeur qui indique s’il faut initialiser un nouveau groupe ou rejoindre un groupe existant. `1` initialise un nouveau groupe avec l’instance de base de données actuelle. `0` associe l’instance de base de données actuelle à un groupe existant en se connectant aux points de terminaison définis dans le paramètre `group_replication_group_seeds` du groupe de paramètres de base de données associé à l’instance de base de données.
### exemple
L’exemple suivant initialise un nouveau groupe avec l’instance de base de données actuelle :
```
CALL mysql.rds_group_replication_start(1);
```
## mysql.rds\$1group\$1replication\$1stop
Arrête la réplication de groupe sur l’instance de base de données actuelle.
### Syntaxe
```
CALL mysql.rds_group_replication_stop();
```
### Notes d’utilisation
Lorsque vous arrêtez la réplication sur une instance de base de données, cela n’affecte aucune autre instance de base de données du cluster actif-actif.
# Gestion de la réplication multisource
Les procédures stockées suivantes permettent de configurer et de gérer les canaux de réplication sur un réplica multisource RDS for MySQL. Pour plus d’informations, consultez [Configuration multi-source-replication pour Amazon RDS for MySQL](mysql-multi-source-replication.md).
Ces procédures stockées ne sont disponibles qu’avec les instances de base de données RDS for MySQL exécutant les versions de moteur suivantes :
+ Toutes les versions 8.4
+ 8.0.35 et versions mineures ultérieures
+ 5.7.44 et versions mineures ultérieures
Lorsque vous utilisez des procédures stockées pour gérer la réplication avec un utilisateur de réplication configuré avec `caching_sha2_passwword`, vous devez configurer le protocole TLS en spécifiant `SOURCE_SSL=1`. `caching_sha2_password` est le plugin d’authentification par défaut pour RDS for MySQL 8.4.
**Note**
Bien que cette documentation désigne les instances de base de données source sous le nom d’instances de base de données RDS for MySQL, ces procédures fonctionnent également pour les instances MySQL exécutées en dehors d’Amazon RDS.
**Topics**
+ [
## mysql.rds\$1next\$1source\$1log\$1for\$1channel
](#mysql_rds_next_source_log_for_channel)
+ [
## mysql.rds\$1reset\$1external\$1source\$1for\$1channel
](#mysql_rds_reset_external_source_for_channel)
+ [
## mysql.rds\$1set\$1external\$1source\$1for\$1channel
](#mysql_rds_set_external_source_for_channel)
+ [
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel
](#mysql_rds_set_external_source_with_auto_position_for_channel)
+ [
## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel
](#mysql_rds_set_external_source_with_delay_for_channel)
+ [
## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel
](#mysql_rds_set_source_auto_position_for_channel)
+ [
## mysql.rds\$1set\$1source\$1delay\$1for\$1channel
](#mysql_rds_set_source_delay_for_channel)
+ [
## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel
](#mysql_rds_skip_repl_error_for_channel)
+ [
## mysql.rds\$1start\$1replication\$1for\$1channel
](#mysql_rds_start_replication_for_channel)
+ [
## mysql.rds\$1start\$1replication\$1until\$1for\$1channel
](#mysql_rds_start_replication_until_for_channel)
+ [
## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel
](#mysql_rds_start_replication_until_gtid_for_channel)
+ [
## mysql.rds\$1stop\$1replication\$1for\$1channel
](#mysql_rds_stop_replication_for_channel)
## mysql.rds\$1next\$1source\$1log\$1for\$1channel
Modifie la position du journal de l’instance de base de données source au début du journal binaire suivant sur l’instance de base de données source du canal. N’utilisez cette procédure que si vous recevez une erreur 1236 d’E/S de réplication sur un réplica multisource.
### Syntaxe
```
CALL mysql.rds_next_source_log_for_channel(
curr_master_log,
channel_name
);
```
### Paramètres
*curr\$1master\$1log*
Index du fichier journal source actuel. Par exemple, si le fichier en cours se nomme `mysql-bin-changelog.012345`, l’index est 12345. Pour déterminer le nom du fichier journal actuel, exécutez la commande `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` et affichez le champ `Source_Log_File`.
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_next_source_log_for_channel`. En cas d’erreur IO\$1Thread, par exemple, vous pouvez utiliser cette procédure pour ignorer tous les événements du fichier journal binaire actuel et reprendre la réplication à partir du fichier journal binaire suivant pour le canal spécifié dans `channel_name`.
### exemple
Supposons que la réplication échoue sur un canal d’un réplica multisource. L’exécution de `SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G` sur le réplica multisource renvoie le résultat suivant :
```
mysql> SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: ReplicationUser
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: replica-relay-bin.000003
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:.
.
.
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
.
.
Channel_name: channel_1
.
.
-- Some fields are omitted in this example output
```
Le champ `Last_IO_Errno` montre que l’instance reçoit une erreur 1236 d’I/O. Le champ `Source_Log_File` montre que le nom du fichier est `mysql-bin-changelog.012345`, ce qui signifie que l’index du fichier journal est `12345`. Pour résoudre l’erreur, vous pouvez appeler `mysql.rds_next_source_log_for_channel` avec les paramètres suivants :
```
CALL mysql.rds_next_source_log_for_channel(12345,'channel_1');
```
## mysql.rds\$1reset\$1external\$1source\$1for\$1channel
Arrête le processus de réplication sur le canal spécifié et supprime le canal et les configurations associées du réplica multisource.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l'activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_reset_external_source_for_channel (channel_name);
```
### Paramètres
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_reset_external_source_for_channel`. Cette procédure supprime tous les journaux de relais appartenant au canal à supprimer.
## mysql.rds\$1set\$1external\$1source\$1for\$1channel
Configure un canal de réplication sur une instance de base de données RDS for MySQL afin de répliquer les données d’une autre instance de base de données RDS for MySQL.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l'activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
**Note**
Vous pouvez plutôt utiliser la procédure stockée [mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel](#mysql_rds_set_external_source_with_delay_for_channel) pour configurer ce canal avec une réplication différée.
### Syntaxe
```
CALL mysql.rds_set_external_source_for_channel (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
, channel_name
);
```
### Paramètres
*host\$1name*
Nom d’hôte ou adresse IP de l’instance de base de données source RDS for MySQL.
*host\$1port*
Port utilisé par l’instance de base de données source RDS for MySQL. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source RDS for MySQL. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance de base de données source.
*replication\$1user\$1password*
Mot de passe de l'ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source qui contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW BINARY LOG STATUS` sur l’instance de base de données source.
Les versions précédentes de MySQL utilisaient `SHOW MASTER STATUS` à la place de `SHOW BINARY LOG STATUS`. Si vous utilisez une version MySQL antérieure à la version 8.4, utilisez alors `SHOW MASTER STATUS`.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d'utiliser le chiffrement SSL, et la valeur 0 de ne pas l'utiliser. La valeur par défaut est 0.
L'option `SOURCE_SSL_VERIFY_SERVER_CERT` n'est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*channel\$1name*
Nom du canal de réplication. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_source_for_channel`. Cette procédure doit être exécutée sur l’instance de base de données RDS for MySQL cible sur laquelle vous créez le canal de réplication.
Avant d’exécuter `mysql.rds_set_external_source_for_channel`, configurez un utilisateur de réplication sur l’instance de base de données source avec les privilèges requis pour le réplica multisource. Pour connecter le réplica multisource à l’instance de base de données source, vous devez spécifier les valeurs `replication_user_name` et `replication_user_password` d’un utilisateur de réplication disposant d’autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source.
**Pour configurer un utilisateur de réplication sur l’instance de base de données source**
1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance de base de données source et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de.
**Important**
En tant que bonne pratique de sécurité, spécifiez un mot de passe autre que la valeur d’espace réservé indiquée dans les exemples suivants.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Sur l’instance de base de données source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com';
```
Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL.
Après avoir appelé `mysql.rds_set_external_source_for_channel` pour configurer ce canal de réplication, vous pouvez appeler [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sur le réplica pour démarrer le processus de réplication sur le canal. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) pour arrêter la réplication sur le canal et supprimer la configuration du canal du réplica.
Lorsque vous appelez `mysql.rds_set_external_source_for_channel`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set channel source` dans la table `mysql.rds_history` sans informations spécifiques au canal, et dans la table `mysql.rds_replication_status` avec le nom du canal. Ces informations sont enregistrées uniquement à des fins d’utilisation interne et de surveillance. Pour enregistrer l’appel de procédure complet à des fins d’audit, pensez à activer les journaux d’audit ou généraux, en fonction des exigences spécifiques de votre application.
### Exemples
Lorsqu’il est exécuté sur une instance de base de données RDS for MySQL, l’exemple suivant configure un canal de réplication nommé `channel_1` sur cette instance de base de données, pour répliquer les données à partir de la source spécifiée par l’hôte `sourcedb.example.com` et le port `3306`.
```
call mysql.rds_set_external_source_for_channel(
'sourcedb.example.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
0,
'channel_1');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel
Configure un canal de réplication sur une instance de base de données RDS for MySQL avec un délai de réplication facultatif. La réplication est basée sur des identifiants de transaction globaux (GTID).
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l'activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source_with_auto_position_for_channel (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
, delay
, channel_name
);
```
### Paramètres
*host\$1name*
Nom d’hôte ou adresse IP de l’instance de base de données source RDS for MySQL.
*host\$1port*
Port utilisé par l’instance de base de données source RDS for MySQL. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source RDS for MySQL. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance de base de données source.
*replication\$1user\$1password*
Mot de passe de l'ID utilisateur spécifié dans `replication_user_name`.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d'utiliser le chiffrement SSL, et la valeur 0 de ne pas l'utiliser. La valeur par défaut est 0.
L'option `SOURCE_SSL_VERIFY_SERVER_CERT` n'est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
*channel\$1name*
Nom du canal de réplication. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_source_with_auto_position_for_channel`. Cette procédure doit être exécutée sur l’instance de base de données RDS for MySQL cible sur laquelle vous créez le canal de réplication.
Avant d’exécuter `rds_set_external_source_with_auto_position_for_channel`, configurez un utilisateur de réplication sur l’instance de base de données source avec les privilèges requis pour le réplica multisource. Pour connecter le réplica multisource à l’instance de base de données source, vous devez spécifier les valeurs `replication_user_name` et `replication_user_password` d’un utilisateur de réplication disposant d’autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source.
**Pour configurer un utilisateur de réplication sur l’instance de base de données source**
1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance de base de données source et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de.
**Important**
En tant que bonne pratique de sécurité, spécifiez un mot de passe autre que la valeur d’espace réservé indiquée dans les exemples suivants.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Sur l’instance de base de données source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com';
```
Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL.
Avant d’appeler `mysql.rds_set_external_source_with_auto_position_for_channel`, assurez-vous d’appeler [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_gtid_purged) pour définir la variable système `gtid_purged` avec une plage GTID spécifiée à partir d’une source externe.
Après avoir appelé `mysql.rds_set_external_source_with_auto_position_for_channel` pour configurer une instance de base de données Amazon RDS comme réplica en lecture sur un canal spécifique, vous pouvez appeler [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sur le réplica en lecture pour démarrer le processus de réplication sur ce canal.
Après avoir appelé `mysql.rds_set_external_source_with_auto_position_for_channel` pour configurer ce canal de réplication, vous pouvez appeler [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sur le réplica pour démarrer le processus de réplication sur le canal. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) pour arrêter la réplication sur le canal et supprimer la configuration du canal du réplica.
### Exemples
Lorsqu’il est exécuté sur une instance de base de données RDS for MySQL, l’exemple suivant configure un canal de réplication nommé `channel_1` sur cette instance de base de données, pour répliquer les données à partir de la source spécifiée par l’hôte `sourcedb.example.com` et le port `3306`. Il définit le délai de réplication minimum sur une heure (3 600 secondes). Cela signifie qu’une modification provenant de l’instance de base de données source RDS for MySQL n’est pas appliquée sur le réplica multisource pendant au moins une heure.
```
call mysql.rds_set_external_source_with_auto_position_for_channel(
'sourcedb.example.com',
3306,
'repl_user',
'password',
1,
3600,
'channel_1');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel
Configure un canal de réplication sur une instance de base de données RDS for MySQL avec un délai de réplication spécifié.
**Important**
Pour exécuter cette procédure, `autocommit` doit être activé. Pour l'activer, définissez le paramètre `autocommit` sur `1`. Pour plus d’informations sur la modification des paramètres d’instance, consultez [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
### Syntaxe
```
CALL mysql.rds_set_external_source_with_delay_for_channel (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
, delay
, channel_name
);
```
### Paramètres
*host\$1name*
Nom d’hôte ou adresse IP de l’instance de base de données source RDS for MySQL.
*host\$1port*
Port utilisé par l’instance de base de données source RDS for MySQL. Si votre configuration réseau inclut une réplication de port Secure Shell (SSH) qui convertit le numéro de port, spécifiez le numéro de port qui est exposé par SSH.
*replication\$1user\$1name*
ID d’un utilisateur disposant des autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source RDS for MySQL. Nous vous recommandons de fournir un compte qui soit utilisé uniquement pour la réplication avec l’instance de base de données source.
*replication\$1user\$1password*
Mot de passe de l'ID utilisateur spécifié dans `replication_user_name`.
*mysql\$1binary\$1log\$1file\$1name*
Nom du journal binaire sur l’instance de base de données source contient les informations de réplication.
*mysql\$1binary\$1log\$1file\$1location*
Emplacement dans le journal binaire `mysql_binary_log_file_name` à partir duquel la réplication commence à lire les informations de réplication.
Vous pouvez déterminer le nom et l’emplacement du fichier journal binaire en exécutant `SHOW BINARY LOG STATUS` sur l’instance de base de données source.
Les versions précédentes de MySQL utilisaient `SHOW MASTER STATUS` à la place de `SHOW BINARY LOG STATUS`. Si vous utilisez une version MySQL antérieure à la version 8.4, utilisez alors `SHOW MASTER STATUS`.
*ssl\$1encryption*
Valeur indiquant si le chiffrement Secure Socket Layer (SSL) est utilisé sur la connexion de réplication. La valeur 1 spécifie d'utiliser le chiffrement SSL, et la valeur 0 de ne pas l'utiliser. La valeur par défaut est 0.
L'option `SOURCE_SSL_VERIFY_SERVER_CERT` n'est pas prise en charge. Cette option est définie sur 0, ce qui signifie que la connexion est chiffrée, mais que les certificats ne sont pas vérifiés.
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
*channel\$1name*
Nom du canal de réplication. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_external_source_with_delay_for_channel`. Cette procédure doit être exécutée sur l’instance de base de données RDS for MySQL cible sur laquelle vous créez le canal de réplication.
Avant d’exécuter `mysql.rds_set_external_source_with_delay_for_channel`, configurez un utilisateur de réplication sur l’instance de base de données source avec les privilèges requis pour le réplica multisource. Pour connecter le réplica multisource à l’instance de base de données source, vous devez spécifier les valeurs `replication_user_name` et `replication_user_password` d’un utilisateur de réplication disposant d’autorisations `REPLICATION CLIENT` et `REPLICATION SLAVE` sur l’instance de base de données source.
**Pour configurer un utilisateur de réplication sur l’instance de base de données source**
1. À l’aide du client MySQL de votre choix, connectez-vous à l’instance de base de données source et créez un compte utilisateur à utiliser pour la réplication. Voici un exemple de.
**Important**
En tant que bonne pratique de sécurité, spécifiez un mot de passe autre que la valeur d’espace réservé indiquée dans les exemples suivants.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Sur l’instance de base de données source, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. L’exemple suivant accorde les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données pour l’utilisateur « repl\$1user » de votre domaine.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com';
```
Pour utiliser la réplication chiffrée, configurez l’instance de base de données source de façon à utiliser les connexions SSL.
Après avoir appelé `mysql.rds_set_external_source_with_delay_for_channel` pour configurer ce canal de réplication, vous pouvez appeler [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sur le réplica pour démarrer le processus de réplication sur le canal. Vous pouvez appeler [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) pour arrêter la réplication sur le canal et supprimer la configuration du canal du réplica.
Lorsque vous appelez `mysql.rds_set_external_source_with_delay_for_channel`, Amazon RDS enregistre l’heure, l’utilisateur et une action de `set channel source` dans la table `mysql.rds_history` sans informations spécifiques au canal, et dans la table `mysql.rds_replication_status` avec le nom du canal. Ces informations sont enregistrées uniquement à des fins d’utilisation interne et de surveillance. Pour enregistrer l’appel de procédure complet à des fins d’audit, pensez à activer les journaux d’audit ou généraux, en fonction des exigences spécifiques de votre application.
### Exemples
Lorsqu’il est exécuté sur une instance de base de données RDS for MySQL, l’exemple suivant configure un canal de réplication nommé `channel_1` sur cette instance de base de données, pour répliquer les données à partir de la source spécifiée par l’hôte `sourcedb.example.com` et le port `3306`. Il définit le délai de réplication minimum sur une heure (3 600 secondes). Cela signifie qu’une modification provenant de l’instance de base de données source RDS for MySQL n’est pas appliquée sur le réplica multisource pendant au moins une heure.
```
call mysql.rds_set_external_source_with_delay_for_channel(
'sourcedb.example.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.000777',
120,
1,
3600,
'channel_1');
```
## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel
Définit le mode de réplication pour le canal spécifié de manière à ce qu’il soit basé sur des positions de fichier journal binaire ou sur des identifiants de transaction globaux (GTID).
### Syntaxe
```
CALL mysql.rds_set_source_auto_position_for_channel (
auto_position_mode
, channel_name
);
```
### Paramètres
*auto\$1position\$1mode*
Valeur qui indique si la réplication à utiliser est la réplication basée sur la position de fichier ou la réplication basée sur les identifiants de transaction globaux :
+ `0` – Utiliser la méthode de réplication basée sur la position du fichier journal binaire. La valeur par défaut est `0`.
+ `1` – Utiliser la méthode de réplication basée sur les identifiants de transaction globaux.
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_source_auto_position_for_channel`. Cette procédure redémarre la réplication sur le canal spécifié pour appliquer le mode de positionnement automatique spécifié.
### Exemples
L’exemple suivant définit le mode de positionnement automatique pour channel\$11 afin d’utiliser la méthode de réplication basée sur le GTID.
```
call mysql.rds_set_source_auto_position_for_channel(1,'channel_1');
```
## mysql.rds\$1set\$1source\$1delay\$1for\$1channel
Définit le nombre minimum de secondes pour retarder la réplication de l’instance de base de données source vers le réplica multisource pour le canal spécifié.
### Syntaxe
```
CALL mysql.rds_set_source_delay_for_channel(delay, channel_name);
```
### Paramètres
*delay*
Nombre minimum de secondes pour retarder la réplication à partir de l’instance de base de données source.
La limite de ce paramètre est une journée (soit 86 400 secondes).
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_set_source_delay_for_channel`. Pour utiliser cette procédure, appelez d’abord `mysql.rds_stop_replication_for_channel` pour arrêter la réplication. Appelez ensuite cette procédure pour définir la valeur du délai de réplication. Lorsque le délai est défini, appelez `mysql.rds_start_replication_for_channel` pour redémarrer la réplication.
### Exemples
L’exemple suivant définit le délai de réplication à partir de l’instance de base de données source sur le `channel_1` du réplica multisource pendant au moins un heure (3 600 secondes).
```
CALL mysql.rds_set_source_delay_for_channel(3600,'channel_1');
```
## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel
Ignore un événement du journal binaire et supprime une erreur de réplication sur un réplica multisource de base de données MySQL pour le canal spécifié.
### Syntaxe
```
CALL mysql.rds_skip_repl_error_for_channel(channel_name);
```
### Paramètres
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_repl_error_for_channel` sur un réplica en lecture. Vous pouvez utiliser cette procédure de la même manière que `mysql.rds_skip_repl_error` pour ignorer une erreur sur un réplica en lecture. Pour plus d’informations, consultez [Appel de la procédure mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure).
**Note**
Pour ignorer les erreurs lors de la réplication basée sur le GTID, nous vous recommandons plutôt d’utiliser la procédure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid).
Pour déterminer s’il y a des erreurs, exécutez la commande MySQL `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G`. Si une erreur de réplication n’est pas critique, vous pouvez exécuter `mysql.rds_skip_repl_error_for_channel` pour ignorer l’erreur. S’il y a plusieurs erreurs, `mysql.rds_skip_repl_error_for_channel` supprime la première sur le canal de réplication spécifié, puis avertit qu’il y a d’autres erreurs. Vous pouvez alors utiliser `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` pour déterminer l’action appropriée pour l’erreur suivante. Pour obtenir des informations sur les valeurs renvoyées, consultez [Instruction SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) dans la documentation sur MySQL.
## mysql.rds\$1start\$1replication\$1for\$1channel
Lance la réplication à partir d’une instance de bases de données RDS for MySQL vers un réplica multisource sur le canal spécifié.
**Note**
Vous pouvez utiliser la procédure stockée [mysql.rds\$1start\$1replication\$1until\$1for\$1channel](#mysql_rds_start_replication_until_for_channel) ou [mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel](#mysql_rds_start_replication_until_gtid_for_channel) pour lancer la réplication à partir d'une instance de bases de données RDS for MySQL et arrêter la réplication à la position spécifiée dans le fichier journal binaire.
### Syntaxe
```
CALL mysql.rds_start_replication_for_channel(channel_name);
```
### Paramètres
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_for_channel`. Après avoir importé les données à partir de l’instance de base de données source RDS for MySQL, exécutez cette commande sur le réplica multisource pour démarrer la réplication sur le canal spécifié.
### Exemples
L’exemple suivant démarre la réplication sur le `channel_1` du réplica multisource.
```
CALL mysql.rds_start_replication_for_channel('channel_1');
```
## mysql.rds\$1start\$1replication\$1until\$1for\$1channel
Lance la réplication à partir d’une instance de bases de données RDS for MySQL sur le canal spécifié et arrête la réplication à la position spécifiée dans le fichier journal binaire.
### Syntaxe
```
CALL mysql.rds_start_replication_until_for_channel (
replication_log_file
, replication_stop_point
, channel_name
);
```
### Paramètres
*replication\$1log\$1file*
Nom du journal binaire sur l’instance de base de données source contient les informations de réplication.
*replication\$1stop\$1point *
Position dans le journal binaire `replication_log_file` à laquelle la réplication s’arrêtera.
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until_for_channel`. Avec cette procédure, la réplication démarre, puis s’arrête lorsque la position spécifiée du fichier binlog est atteinte. Cette procédure arrête à la fois `SQL_THREAD` et `IO_THREAD`.
Le nom de fichier spécifié pour le paramètre `replication_log_file` doit correspondre au nom du fichier binlog de l’instance de base de données source.
Lorsque le paramètre `replication_stop_point` spécifie une position d’arrêt survenant dans le passé, la réplication est arrêtée immédiatement.
### Exemples
L’exemple suivant lance la réplication sur `channel_1` et réplique les modifications jusqu’à ce qu’il atteigne la position `120` dans le fichier journal binaire `mysql-bin-changelog.000777`.
```
call mysql.rds_start_replication_until_for_channel(
'mysql-bin-changelog.000777',
120,
'channel_1'
);
```
## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel
Lance la réplication sur le canal spécifié à partir d’une instance de bases de données RDS for MySQL et arrête la réplication à la position de l’identifiant de transaction global spécifié (GTID).
### Syntaxe
```
CALL mysql.rds_start_replication_until_gtid_for_channel(gtid,channel_name);
```
### Paramètres
*gtid*
Identifiant de transaction global (GTID) après lequel la réplication s’arrête.
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until_gtid_for_channel`. La procédure démarre la réplication sur le canal spécifié et applique toutes les modifications jusqu’à la valeur GTID spécifiée. Ensuite, elle arrête la réplication sur le canal.
Lorsque le paramètre `gtid` spécifie une transaction ayant déjà été exécutée par le réplica, la réplication est immédiatement arrêtée.
Avant d’exécuter cette procédure, vous devez désactiver la réplication multithread en définissant la valeur de `replica_parallel_workers` ou `slave_parallel_workers` sur `0`.
### Exemples
L’exemple suivant lance la réplication sur `channel_1` et réplique les modifications jusqu’à ce que le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` soit atteint.
```
call mysql.rds_start_replication_until_gtid_for_channel('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','channel_1');
```
## mysql.rds\$1stop\$1replication\$1for\$1channel
Arrête la réplication à partir d’une instance de base de données MySQL sur le canal spécifié.
### Syntaxe
```
CALL mysql.rds_stop_replication_for_channel(channel_name);
```
### Paramètres
*channel\$1name*
Nom du canal de réplication sur le réplica multisource. Chaque canal de réplication reçoit les événements du journal binaire d’une instance de base de données RDS for MySQL à source unique exécutée sur un hôte et un port spécifiques.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_stop_replication_for_channel`.
### Exemples
L’exemple suivant arrête la réplication sur le `channel_1` du réplica multisource.
```
CALL mysql.rds_stop_replication_for_channel('channel_1');
```
# Répliquer des transactions à l'aide de GTIDs
Les procédures stockées suivantes contrôlent la façon dont les transactions sont répliquées à l'aide des identificateurs de transaction globaux (GTIDs) avec RDS pour MySQL. Pour plus d'informations sur la réplication basée sur GTIDs RDS pour MySQL, consultez[Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Lorsque vous utilisez des procédures stockées pour gérer la réplication avec un utilisateur de réplication configuré avec `caching_sha2_password`, vous devez configurer le protocole TLS en spécifiant `SOURCE_SSL=1`. `caching_sha2_password` est le plugin d’authentification par défaut pour RDS for MySQL 8.4.
**Topics**
+ [
##
](#mysql_rds_skip_transaction_with_gtid)
+ [
##
](#mysql_rds_start_replication_until_gtid)
##
Ignore la réplication d’une transaction avec l’identifiant de transaction global (GTID) spécifié sur une instance de base de données MySQL.
Vous pouvez utiliser cette procédure pour la reprise après sinistre lorsqu’il est avéré qu’une transaction GTID entraîne des problèmes. Utilisez cette procédure stockée pour ignorer la transaction problématique. Les transactions problématiques sont par exemple celles qui désactivent la réplication, suppriment des données importantes ou entraînent l’indisponibilité de l’instance de base de données.
### Syntaxe
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### Parameters
*gtid\$1to\$1skip*
GTID de la transaction de réplication à ignorer.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_skip_transaction_with_gtid`.
Cette procédure est prise en charge pour toutes les versions de RDS for MySQL 5.7, toutes les version de RDS for MySQL 8.0 et toutes les versions de RDS for MySQL 8.4.
### Exemples
L’exemple suivant ignore la réplication de la transaction avec le GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
##
Lance la réplication à partir d’une instance de base de données RDS for MySQL et arrête la réplication immédiatement après l’identifiant de transaction global (GTID) spécifié.
### Syntaxe
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### Parameters
*gtid*
Identifiant de transaction global (GTID) après lequel la réplication s’arrête.
### Notes d’utilisation
L’utilisateur principal doit exécuter la procédure `mysql.rds_start_replication_until_gtid`.
Cette procédure est prise en charge pour toutes les versions de RDS for MySQL 5.7, toutes les version de RDS for MySQL 8.0 et toutes les versions de RDS for MySQL 8.4.
Vous pouvez utiliser cette procédure avec la réplication retardée pour la reprise après sinistre. Si vous avez configuré la réplication retardée, vous pouvez utiliser cette procédure pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre. Une fois que cette procédure a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Vous pouvez configurer la réplication retardée en utilisant les procédures stockées suivantes :
+ [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay)
+ [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay)
Lorsque le paramètre `gtid` spécifie une transaction ayant déjà été exécutée par le réplica, la réplication est immédiatement arrêtée.
### Exemples
L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce que le GTID soit atteint `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`.
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# Rotation des journaux de requêtes
Les procédures stockées suivantes effectuent la rotation des journaux MySQL vers des tables de sauvegarde. Pour plus d’informations, consultez [Fichiers journaux de base de données MySQL](USER_LogAccess.Concepts.MySQL.md).
**Topics**
+ [
## mysql.rds\$1rotate\$1general\$1log
](#mysql_rds_rotate_general_log)
+ [
## mysql.rds\$1rotate\$1slow\$1log
](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
Convertit la table `mysql.general_log` en table de sauvegarde.
### Syntaxe
```
CALL mysql.rds_rotate_general_log;
```
### Notes d'utilisation
Vous pouvez convertir la table `mysql.general_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_general_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde. Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.general_log` est nommée `mysql.general_log_backup`.
Vous ne pouvez exécuter cette procédure que lorsque le paramètre `log_output` est défini sur `TABLE`.
## mysql.rds\$1rotate\$1slow\$1log
Convertit la table `mysql.slow_log` en table de sauvegarde.
### Syntaxe
```
CALL mysql.rds_rotate_slow_log;
```
### Notes d'utilisation
Vous pouvez convertir la table `mysql.slow_log` en table de sauvegarde en appelant la procédure `mysql.rds_rotate_slow_log`. Lors de la rotation des tables de journaux, la table de journal actuelle est copiée vers une table de journal de sauvegarde et les entrées de la table de journal actuelle sont supprimées. Si la table du journal de sauvegarde existe déjà, elle est supprimée avant que la table du journal active ne soit copiée dans la sauvegarde.
Si besoin, vous pouvez interroger la table de journal de sauvegarde. La table de journal de sauvegarde de la table `mysql.slow_log` est nommée `mysql.slow_log_backup`.
# Configuration et affichage de la configuration du journal binaire
Les procédures stockées suivantes définissent et affichent les paramètres de configuration, tels que la conservation des fichiers journaux binaires.
**Topics**
+ [
## mysql.rds\$1set\$1configuration
](#mysql_rds_set_configuration)
+ [
## mysql.rds\$1show\$1configuration
](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
Spécifie le nombre d’heures pendant lequel les journaux binaires doivent être conservés ou le nombre de secondes pendant lequel retarder la réplication.
### Syntaxe
```
CALL mysql.rds_set_configuration(name,value);
```
### Parameters
*name*
Nom du paramètre de configuration à définir.
*value*
Valeur du paramètre de configuration.
### Notes d’utilisation
La procédure `mysql.rds_set_configuration` prend en charge des paramètres de configuration suivants :
+ [nombre d’heures de conservation du journal binaire](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
+ [retard à la source](#mysql_rds_set_configuration-usage-notes.source-delay)
+ [target delay](#mysql_rds_set_configuration-usage-notes.target-delay)
Les paramètres de configuration sont stockés de manière permanente et survivent à tout redémarrage ou basculement d’une instance de base de données.
#### nombre d’heures de conservation du journal binaire
Le paramètre `binlog retention hours` est utilisé pour spécifier le nombre d’heures de rétention des fichiers journaux binaires. Amazon RDS purge normalement un journal binaire dès que possible, mais il se peut que le journal binaire soit encore requis pour la réplication avec une base de données MySQL extérieure à RDS.
La valeur par défaut de `binlog retention hours` est `NULL`. Pour RDS pour MySQL, `NULL` signifie que les journaux binaires ne sont pas conservés (0 heure).
Pour spécifier le nombre d’heures pendant lesquelles conserver les journaux binaires sur une instance, utilisez la procédure stockée `mysql.rds_set_configuration` et spécifiez une période suffisamment longue pour que la réplication se produise, comme illustré dans l’exemple suivant.
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**Note**
Vous ne pouvez pas utiliser la valeur `0` pour `binlog retention hours`.
Pour les instances de base de données MySQL, la valeur `binlog retention hours` maximale est 168 (7 jours).
Après avoir défini la période de rétention, surveillez l’utilisation du stockage de l’instance de base de données afin de garantir que les journaux binaires conservés n’utilisent pas un espace de stockage trop grand.
Pour les déploiements de cluster de bases de données multi-AZ, vous pouvez uniquement configurer la conservation des journaux binaires à partir de l’instance de base de données de l’enregistreur, et le paramètre est propagé à toutes les instances de base de données de lecteur de manière asynchrone. Si les journaux binaires du cluster de bases de données dépassent la moitié de l’espace de stockage local total, Amazon RDS déplace automatiquement les journaux périmés vers le volume EBS. Cependant, les journaux les plus récents restent stockés localement ; ils risquent donc d’être perdus en cas de défaillance nécessitant le remplacement de l’hôte ou lors d’une mise à l’échelle à la hausse ou à la baisse de la base de données.
#### retard à la source
Utilisez le paramètre `source delay` dans un réplica en lecture pour spécifier le nombre de secondes dont il faut retarder la réplication à partir du réplica en lecture vers son instance de base de données source. Amazon RDS réplique normalement les modifications dès que possible, mais vous pouvez souhaiter que certains environnement retardent la réplication. Par exemple, lorsque la réplication est retardée, vous pouvez restaurer par progression un réplica en lecture retardé au moment précédant un sinistre. Si une table est supprimée par mégarde, vous pouvez utiliser la réplication retardée pour la récupérer rapidement. La valeur par défaut de `target delay` est `0` (ne pas retarder la réplication).
Lorsque vous utilisez ce paramètre, il exécute [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) et applique la valeur d’entrée CHANGE primary TO MASTER\$1DELAY =. En cas de succès, la procédure enregistre le paramètre `source delay` dans la table `mysql.rds_configuration`.
Pour spécifier le nombre de secondes pendant lesquelles Amazon RDS retardera la réplication vers une instance de base de données source, utilisez la procédure `mysql.rds_set_configuration` stockée et spécifiez le nombre de secondes dont il faut retarder la réplication. Dans l’exemple suivant, la réplication est retardée d’au moins une heure (3 600 secondes).
`call mysql.rds_set_configuration('source delay', 3600);`
La procédure exécute ensuite `mysql.rds_set_source_delay(3600)`.
La limite du paramètre `source delay` est une journée (soit 86 400 secondes).
#### target delay
Utilisez le paramètre `target delay` pour spécifier le nombre de secondes dont il faut retarder la réplication entre une instance de base de données et tout réplica en lecture futur géré par RDS créé à partir de cette instance. Ce paramètre est ignoré pour les répliques de non-RDS-managed lecture. Amazon RDS réplique normalement les modifications dès que possible, mais vous pouvez souhaiter que certains environnement retardent la réplication. Par exemple, lorsque la réplication est retardée, vous pouvez restaurer par progression un réplica en lecture retardé au moment précédant un sinistre. Si une table est supprimée par mégarde, vous pouvez utiliser la réplication retardée pour la récupérer rapidement. La valeur par défaut de `target delay` est `0` (ne pas retarder la réplication).
Pour la reprise après sinistre, vous pouvez utiliser ce paramètre de configuration avec la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ou [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Pour restaurer par progression les modifications dans un réplica en lecture retardé au moment précédant un sinistre, vous pouvez exécuter la procédure `mysql.rds_set_configuration` avec ce paramètre défini. Une fois que la procédure `mysql.rds_start_replication_until` ou `mysql.rds_start_replication_until_gtid` a arrêté la réplication, vous pouvez promouvoir le réplica en lecture pour qu’il devienne la nouvelle instance de base de données principale, en utilisant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
Pour utiliser la procédure `mysql.rds_rds_start_replication_until_gtid`, la réplication basée sur des identifiants de transaction globaux (GTID) doit être activée. Pour ignorer une transaction basée sur des identifiants de transaction globaux spécifique qui est réputée pour entraîner des défaillances, vous pouvez utiliser la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Pour plus d’informations sur la gestion d’une réplication basée sur des identifiants de transaction globaux, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Pour spécifier le nombre de secondes pendant lesquelles Amazon RDS retardera la réplication vers un réplica en lecture, utilisez la procédure stockée `mysql.rds_set_configuration` et spécifiez le nombre de secondes dont il faut retarder la réplication. L’exemple suivant spécifie que la réplication est retardée d’au moins une heure (3 600 secondes).
`call mysql.rds_set_configuration('target delay', 3600);`
La limite du paramètre `target delay` est une journée (soit 86 400 secondes).
## mysql.rds\$1show\$1configuration
Nombre d’heures pendant lequel les journaux binaires sont conservés.
### Syntaxe
```
CALL mysql.rds_show_configuration;
```
### Notes d’utilisation
Pour vérifier le nombre d’heures pendant lequel Amazon RDS conserve les journaux binaires, utilisez la procédure stockée `mysql.rds_show_configuration`.
### Exemples
L’exemple suivant affiche la période de rétention :
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Réchauffement du cache InnoDB
Les procédures stockées suivantes enregistrent, chargent ou annulent le chargement du pool de mémoires tampons InnoDB sur les instances de base de données RDS pour MySQL. Pour de plus amples informations, consultez [Préparation du cache InnoDB pour MySQL sur Amazon RDS](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.InnoDBCacheWarming).
**Topics**
+ [
## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now
](#mysql_rds_innodb_buffer_pool_dump_now)
+ [
## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort
](#mysql_rds_innodb_buffer_pool_load_abort)
+ [
## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now
](#mysql_rds_innodb_buffer_pool_load_now)
## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now
Vide l'état actuel du pool de tampons sur le disque.
### Syntaxe
```
CALL mysql.rds_innodb_buffer_pool_dump_now();
```
### Notes d'utilisation
L'utilisateur principal doit exécuter la procédure `mysql.rds_innodb_buffer_pool_dump_now`.
## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort
Annule un chargement en cours de l'état du groupe de tampons enregistré.
### Syntaxe
```
CALL mysql.rds_innodb_buffer_pool_load_abort();
```
### Notes d'utilisation
L'utilisateur principal doit exécuter la procédure `mysql.rds_innodb_buffer_pool_load_abort`.
## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now
Charge l'état enregistré du pool de tampons à partir du disque.
### Syntaxe
```
CALL mysql.rds_innodb_buffer_pool_load_now();
```
### Notes d'utilisation
L'utilisateur principal doit exécuter la procédure `mysql.rds_innodb_buffer_pool_load_now`.