engine=innodb, algorithm=copy;
```
Dans les sections suivantes, configurez la réplication, arrêtez la réplication, mettez à l’échelle les lectures pour votre base de données, optimisez la réplication des journaux binaires et configurez le journal binaire amélioré.
**Topics**
+ [Configuration de la réplication des journaux binaires pour Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Arrêt de la réplication des journaux binaires pour Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Mise à l’échelle des lectures pour votre base de données MySQL avec Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md)
+ [Optimisation de la réplication des journaux binaires pour Aurora MySQL](binlog-optimization.md)
+ [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md)
# Configuration de la réplication des journaux binaires pour Aurora MySQL
La configuration de la réplication MySQL avec Aurora MySQL implique les étapes suivantes, qui sont présentées en détail :
**Contents**
+ [1. Activer la journalisation binaire sur la source de réplication](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. Créer une copie ou un vidage de votre source de réplication](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. Charger le vidage dans votre cible de réplica (si nécessaire)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. Créer un utilisateur de réplication sur votre source de réplication](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. Activer la réplication sur votre cible de réplica](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [Définition d’une position où arrêter la réplication vers un réplica en lecture](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. Surveiller votre réplica](#AuroraMySQL.Replication.MySQL.Monitor)
+ [Synchronisation des mots de passe entre la source de réplication et la cible](#AuroraMySQL.Replication.passwords)
## 1. Activer la journalisation binaire sur la source de réplication
Vous trouverez des instructions sur la façon d’activer la journalisation binaire sur la source de réplication pour votre moteur de base de données ci-après.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL** Définissez le paramètre de cluster de bases de données `binlog_format` sur `ROW`, `STATEMENT` ou `MIXED`. La valeur `MIXED` est recommandée sauf si vous avez besoin d’un format de journal binaire spécifique. (La valeur par défaut est `OFF`.) Pour modifier le paramètre `binlog_format`, créez un groupe de paramètres de cluster de bases de données personnalisé et associez ce groupe de paramètres personnalisé à votre cluster de bases de données. Vous ne pouvez pas modifier les paramètres dans le groupe de paramètres de cluster de bases de données par défaut. Si vous modifiez le paramètre `binlog_format` en remplaçant `OFF` par une autre valeur, redémarrez votre cluster de bases de données Aurora pour que la modification prenne effet. Pour plus d’informations, consultez [Paramètres de cluster de bases de données et d’instance de base de données Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) et [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). |
| RDS for MySQL | **Pour activer la journalisation binaire sur une instance de base de données Amazon RDS** Vous ne pouvez pas activer la journalisation binaire directement pour une instance de base de données Amazon RDS, mais vous pouvez l’activer en exécutant l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externe) | **Pour configurer la réplication chiffrée** Pour répliquer des données en toute sécurité avec Aurora MySQL version 2, vous pouvez utiliser la réplication chiffrée. Si vous n’avez pas besoin d’utiliser la réplication chiffrée, vous pouvez ignorer ces étapes. Pour pouvoir utiliser la réplication chiffrée, vous devez impérativement disposer des éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pendant la réplication chiffrée, le cluster de bases de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour activer la journalisation binaire sur une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires
Lorsque vous utilisez la réplication des journaux binaires MySQL, Amazon RDS ne gère pas le processus de réplication. En conséquence, vous devez vous assurer que les fichiers des journaux binaires sur votre source de réplication sont conservés jusqu’après que les modifications ont été appliquées au réplica. Cette maintenance vous permet de restaurer votre base de données source en cas de panne.
Suivez les instructions suivantes pour conserver les journaux binaires de votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour conserver les journaux binaires sur un cluster de bases de données Aurora MySQL** Vous n’avez pas accès aux fichiers journaux binaires pour un cluster de bases de données Aurora MySQL. En conséquence, vous devez choisir une période assez longue de conservation des fichiers journaux binaires sur votre source de réplication pour être assuré que les modifications ont été appliquées à votre réplica avant que le fichier journal binaire ne soit supprimé par Amazon RDS. Vous pouvez conserver les fichiers journaux binaires sur un cluster de bases de données Aurora MySQL pendant 90 jours maximum. Si vous configurez la réplication avec une base de données MySQL ou une instance de base de données RDS for MySQL comme réplica, et que la base de données pour laquelle vous créez un réplica est très volumineuse, choisissez une durée conséquente pour conserver les fichiers journaux binaires jusqu’à ce que la copie initiale de la base de données sur le réplica soit complète et que le retard du réplica ait atteint la valeur 0. 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. La valeur maximum pour Aurora MySQL versions 2.11.0 et ultérieures et version 3 est 2 160 (90 jours). L’exemple suivant définit la période de rétention des fichiers journaux binaires sur 6 jours : CALL mysql.rds_set_configuration('binlog retention hours', 144); Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ `Seconds behind master`. Si la valeur du champ `Seconds behind master` est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, réduisez la période pendant laquelle les fichiers journaux binaires sont conservés en définissant le paramètre de configuration `binlog retention hours` sur une durée plus petite. Si ce paramètre n’est pas spécifié, la valeur par défaut pour Aurora MySQL est 24 (1 jour). Si vous spécifiez une valeur supérieure à la valeur maximale pour `'binlog retention hours'`, Aurora MySQL utilise la valeur maximale. |
| RDS for MySQL | **Pour conserver les journaux binaires sur une instance de base de données Amazon RDS** Vous pouvez conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en définissant les heures de conservation des journaux binaires comme vous le feriez pour un cluster de bases de données Aurora MySQL (procédure décrite à la ligne précédente). Vous pouvez également conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en créant un réplica en lecture pour l’instance de base de données. Ce réplica en lecture a pour seul but temporaire et exclusif de conserver les fichiers journaux binaires. Une fois le réplica en lecture créé, appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) sur le réplica en lecture. Lorsque la réplication est arrêtée, Amazon RDS ne supprime aucun des fichiers journaux binaires sur la source de réplication. Après avoir configuré la réplication avec votre réplica permanent, vous pouvez supprimer le réplica en lecture lorsque le retard du réplica (champ `Seconds behind master`) entre votre source de réplication et votre réplica permanent atteint 0. |
| MySQL (externe) | **Pour conserver les journaux binaires sur une base de données MySQL externe** Comme les fichiers journaux binaires sur une base de données MySQL externe ne sont pas gérés par Amazon RDS, ils sont conservés jusqu’à ce que vous les supprimiez. Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ `Seconds behind master`. Si la valeur du champ `Seconds behind master` est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, vous pouvez supprimer les anciens fichiers journaux binaires. |
## 3. Créer une copie ou un vidage de votre source de réplication
Vous utilisez un instantané, un clone ou un vidage de votre source de réplication pour charger une copie de référence de vos données sur votre réplica. Ensuite, vous commencez la réplication à partir de ce point.
Utilisez les instructions suivantes pour créer une copie ou un vidage de votre source de réplication pour votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour créer une copie d’un cluster de bases de données Aurora MySQL** Utilisez l’une des méthodes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour déterminer le nom et la position du fichier binlog** Utilisez l’une des méthodes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour créer un vidage d’un cluster de bases de données Aurora MySQL** Si votre cible de réplica est une base de données MySQL externe ou une instance de base de données RDS for MySQL, vous devez créer un fichier de vidage à partir de votre cluster de bases de données Aurora. Veillez bien à exécuter la commande `mysqldump` sur la copie du cluster de bases de données Aurora que vous avez créée. Cela permet d’éviter le verrouillage des tables sources lors du vidage. Si le vidage était effectué directement sur le cluster de bases de données source, il serait nécessaire de verrouiller ces tables pour empêcher les écritures simultanées pendant le vidage. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Pour créer un instantané d’une instance de base de données Amazon RDS** Créez un réplica en lecture de votre instance de base de données Amazon RDS. Pour plus d’informations, consultez [Création d’un réplica en lecture](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) dans le *Guide de l’utilisateur Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externe) | **Pour créer un vidage d’une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. Charger le vidage dans votre cible de réplica (si nécessaire)
Si vous prévoyez de charger les données à partir d’un vidage d’une base de données MySQL externe à Amazon RDS, vous souhaiterez peut-être créer une instance EC2 sur laquelle copier les fichiers de vidage. Vous pourrez ensuite charger les données dans votre cluster de bases de données ou votre instance de base de données à partir de cette instance EC2. À l’aide de cette approche, vous pouvez compresser les fichiers de vidage avant de les copier sur l’instance EC2 afin de réduire les coûts réseau associés à la copie des données sur Amazon RDS. Vous pouvez aussi chiffrer les fichiers de vidage pour sécuriser les données tandis qu’elles sont transférées sur le réseau.
**Note**
Si vous créez un cluster de bases de données Aurora MySQL comme cible de réplica, vous n’avez pas besoin de charger un fichier de vidage :
Vous pourrez ultérieurement restaurer un cluster de bases de données pour créer le cluster. Pour plus d’informations, consultez [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md).
Vous pouvez cloner votre cluster de bases de données source pour créer un cluster de bases de données. Pour plus d’informations, consultez [Clonage d’un volume pour un cluster de bases de données Amazon Aurora](Aurora.Managing.Clone.md).
Vous pouvez migrer les données d’un instantané d’instance de base de données vers un nouveau cluster de bases de données. Pour plus d’informations, consultez [Migration de données vers un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Migrating.md).
Utilisez les instructions suivantes pour charger le vidage de votre source de réplication dans votre cible de réplica pour votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour charger un vidage dans un cluster de bases de données Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Pour charger un vidage dans une instance de base de données Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (externe) | **Pour charger un vidage dans une base de données MySQL externe** Vous ne pouvez pas charger un instantané de base de données ou un instantané de cluster de bases de données dans une base de données MySQL externe. A la place, vous devez utiliser la sortie de la commande `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. Créer un utilisateur de réplication sur votre source de réplication
Créez un ID utilisateur sur la source qui est utilisé uniquement pour la réplication. L’exemple suivant concerne RDS for MySQL ou les bases de données sources MySQL externes.
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
Pour les bases de données source Aurora MySQL, le paramètre de cluster de bases de données `skip_name_resolve` est défini sur `1` (`ON`) et ne peut pas être modifié. Vous devez donc utiliser une adresse IP pour l’hôte au lieu d’un nom de domaine. Pour plus d’informations, consultez [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) dans la documentation MySQL.
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
L’utilisateur nécessite les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE`. Accordez ces privilèges à l’utilisateur.
Si vous avez besoin d’utiliser la réplication chiffrée, demandez des connexions SSL à l’utilisateur de la réplication. Par exemple, vous pouvez utiliser l’une des instructions suivantes pour demander les connexions SSL sur le compte d’utilisateur `repl_user`.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**Note**
Si `REQUIRE SSL` n’est pas inclus, la connexion de réplication peut revenir de façon silencieuse à une connexion non chiffrée.
## 6. Activer la réplication sur votre cible de réplica
Avant d’activer la réplication, nous vous recommandons de prendre un instantané manuel du cluster de bases de données Aurora MySQL ou de la cible de réplica de l’instance de base de données RDS for MySQL. Si un problème survient et que vous avez besoin de rétablir la réplication avec la cible de réplica du cluster de bases de données ou de l’instance de base de données, vous pouvez restaurer le cluster de bases de données ou l’instance de base de données à partir de cet instantané au lieu de devoir importer à nouveau les données dans votre cible de réplica.
Suivez les instructions suivantes pour activer la réplication pour votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour activer la réplication à partir d’un cluster de bases de données Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pour utiliser le chiffrement SSL, définissez la valeur finale sur `1` au lieu de `0`. |
| RDS for MySQL | **Pour activer la réplication à partir d’une instance de base de données Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pour utiliser le chiffrement SSL, définissez la valeur finale sur `1` au lieu de `0`. |
| MySQL (externe) | **Pour activer la réplication à partir d’une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
En cas d'échec de la réplication, cela peut entraîner une augmentation importante du nombre de répliques involontaires I/O , ce qui peut dégrader les performances. Si la réplication échoue ou n’est plus nécessaire, vous pouvez exécuter la procédure stockée [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ou [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) pour supprimer la configuration de réplication.
### Définition d’une position où arrêter la réplication vers un réplica en lecture
Dans Aurora MySQL versions 3.04 et ultérieures, 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.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](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. À l’aide d’un client MySQL, connectez-vous au cluster de bases de données Aurora MySQL du réplica en tant qu’utilisateur principal.
1. Exécutez la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](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`.
Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) au lieu de la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](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).
## 7. Surveiller votre réplica
Lorsque vous configurez la réplication MySQL avec un cluster de bases de données Aurora MySQL, vous devez surveiller les événements de basculement du cluster de bases de données Aurora MySQL quand il s’agit de la cible de réplica. En cas de basculement, le cluster de bases de données qui est votre cible de réplica peut alors être recréé sur un nouvel hôte avec une adresse réseau différente. 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).
Vous pouvez aussi surveiller à quelle distance la cible de réplica se trouve de la source de réplication en vous connectant à la cible de réplica et en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3). Dans la sortie de la commande, le champ `Seconds Behind Master` vous indique à quelle distance la cible de réplica se trouve de la source de réplication.
**Important**
Si vous mettez à niveau votre cluster de bases de données et que vous spécifiez un groupe de paramètres personnalisé, assurez-vous de redémarrer manuellement le cluster une fois la mise à niveau terminée. Cela obligera le cluster à utiliser vos nouveaux paramètres personnalisés et redémarrera la réplication des journaux binaires.
## Synchronisation des mots de passe entre la source de réplication et la cible
Lorsque vous modifiez des comptes d’utilisateur et des mots de passe sur la source de réplication à l’aide d’instructions SQL, ces modifications sont automatiquement répliquées sur la cible de réplication.
Si vous utilisez l'API AWS Management Console AWS CLI, la ou l'API RDS pour modifier le mot de passe principal sur la source de réplication, ces modifications ne sont pas automatiquement répliquées sur la cible de réplication. Si vous souhaitez synchroniser l’utilisateur principal et le mot de passe principal entre les systèmes source et cible, vous devez effectuer vous-même la même modification sur la cible de réplication.
# Arrêt de la réplication des journaux binaires pour Aurora MySQL
Pour arrêter la réplication des journaux binaires avec une instance de base de données MySQL, une base de données MySQL externe ou un autre cluster Aurora DB, suivez les étapes présentées en détail dans la suite de cette rubrique.
[1. Arrêter la réplication des journaux binaires sur la cible de réplica](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. Désactiver la journalisation binaire sur la source de réplication](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. Arrêter la réplication des journaux binaires sur la cible de réplica
Utilisez les instructions suivantes pour arrêter la réplication des journaux binaires pour votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour arrêter la réplication des journaux binaires sur une cible de réplica de cluster de bases de données Aurora MySQL** Connectez-vous au cluster de bases de données Aurora qui est la cible de réplica et appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| RDS for MySQL | **Pour arrêter la réplication des journaux binaires sur une instance de base de données Amazon RDS** Connectez-vous à l’instance de base de données RDS qui est la cible de réplica et appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| MySQL (externe) | **Pour arrêter la réplication des journaux binaires sur une base de données MySQL externe** Connectez-vous à la base de données MySQL et exécutez la commande `STOP SLAVE` (version 5.7) ou `STOP REPLICA` (version 8.0). |
## 2. Désactiver la journalisation binaire sur la source de réplication
Utilisez les instructions indiquées dans le tableau suivant pour désactiver la journalisation binaire sur la source de réplication pour votre moteur de base de données.
| Moteur de base de données | Instructions |
| --- | --- |
| Aurora MySQL | **Pour désactiver la journalisation binaire sur un cluster de bases de données Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Pour désactiver la journalisation binaire sur une instance de base de données Amazon RDS** Vous ne pouvez pas désactiver la journalisation binaire directement pour une instance de base de données Amazon RDS, mais vous pouvez la désactiver en procédant comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (externe) | **Pour désactiver la journalisation binaire sur une base de données MySQL externe** Connectez-vous à la base de données MySQL et appelez la commande `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Mise à l’échelle des lectures pour votre base de données MySQL avec Amazon Aurora
Vous pouvez utiliser Amazon Aurora avec votre instance de base de données MySQL pour tirer parti des capacités de mise à l’échelle en lecture d’Amazon Aurora et développer la charge de travail en lecture de votre instance de base de données MySQL. Pour utiliser Aurora afin de mettre à l’échelle les lectures pour votre instance de base de données MySQL, créez un cluster de bases de données Amazon Aurora MySQL et faites-en un réplica en lecture de votre instance de base de données MySQL. Cela s’applique à une instance de base de données RDS for MySQL ou à une base de données MySQL s’exécutant en dehors de Amazon RDS.
Pour plus d’informations sur la création d’un cluster de bases de données Amazon Aurora, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
Lorsque vous configurez la réplication entre votre instance de base de données MySQL et votre cluster de bases de données Amazon Aurora, veillez à respecter les instructions suivantes :
+ Utilisez l’adresse du point de terminaison du cluster de bases de données Amazon Aurora lorsque vous référencez votre cluster de bases de données Amazon Aurora MySQL. Si un basculement se produit, le réplica Aurora qui est promu en instance principale du cluster de bases de données Aurora MySQL continue d’utiliser l’adresse du point de terminaison du cluster de bases de données.
+ Tenez à jour les journaux binaires sur votre instance d’enregistreur jusqu’à ce que vous ayez vérifié qu’ils ont été appliqués au réplica Aurora. Cela garantit que vous pouvez restaurer votre instance d’enregistreur en cas de défaillance.
**Important**
Lorsque vous utilisez une réplication auto-gérée, vous êtes chargé de surveiller et résoudre les problèmes de réplication éventuels. Pour plus d’informations, consultez [Diagnostic et résolution du retard entre réplicas en lecture](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
**Note**
Les autorisations requises pour lancer la réplication sur un cluster de bases de données Aurora MySQL sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Par conséquent, vous devez utiliser les procédures [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](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 cluster de bases de données Aurora MySQL et votre instance de base de données MySQL.
## Démarrer la réplication entre une instance source externe et un cluster de bases de données Aurora MySQL
1. Passez l’instance de base de données MySQL source 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 de base de données MySQL source 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 de base de données MySQL externe vers le cluster de bases de données Amazon Aurora MySQL à l’aide de `mysqldump`. Pour les bases de données très volumineuses, vous pouvez utiliser la procédure décrite dans la section [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) du * Guide de l’utilisateur Amazon Relational Database Service*.
Pour Linux, macOS ou Unix :
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
Pour Windows :
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**Note**
Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi.
Utilisez les options `--host`, `--user (-u)`, `--port` et `-p` de la commande `mysql` pour spécifier le nom d’hôte, le nom d’utilisateur, le port et le mot de passe pour vous connecter à votre cluster de bases de données Aurora. Le nom d’hôte est le nom DNS du point de terminaison du cluster de bases de données Amazon Aurora, par exempl, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de cluster dans Amazon RDS Management Console.
1. Transformez l’instance de base de données MySQL source en instance accessible de nouveau en écriture :
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Pour plus d’informations sur les sauvegardes à utiliser avec la réplication, consultez [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) dans la documentation MySQL.
1. Dans Amazon RDS Management Console, ajoutez l’adresse IP du serveur qui héberge la base de données MySQL source au groupe de sécurité VPC du cluster de bases de données Amazon Aurora. 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*.
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 cluster de bases de données Amazon Aurora, de telle sorte qu’elle puisse communiquer avec votre instance MySQL source. Pour rechercher l’adresse IP du cluster de bases de données Amazon Aurora, utilisez la commande `host`.
```
host aurora_endpoint_address
```
Le nom d’hôte est le nom DNS du point de terminaison du cluster de bases de données Amazon Aurora.
1. À l’aide du client de votre choix, connectez-vous à l’instance MySQL externe et créez un utilisateur MySQL à 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.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Pour l’instance MySQL 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'@'example.com'
IDENTIFIED BY 'password';
```
1. Avant de configurer la réplication, prenez un instantané manuel du cluster de bases de données Aurora MySQL qui constituera le réplica en lecture. Si vous avez besoin de rétablir la réplication avec le cluster de bases de données en tant que réplica en lecture, vous pouvez restaurer le cluster de bases de données Aurora MySQL à partir de cet instantané au lieu de devoir importer les données depuis votre instance de base de données MySQL vers un nouveau cluster de bases de données Aurora MySQL.
1. Transformez le cluster de bases de données Amazon Aurora en réplica. Connectez-vous au cluster de bases de données Amazon Aurora en tant qu’utilisateur principal et identifiez la base de données MySQL source en tant que source de réplication en utilisant les procédures [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication).
Utilisez le nom et la position du fichier binlog que vous avez déterminés à l’étape 2. Voici un exemple.
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. Sur le cluster de bases de données Amazon Aurora, appelez la procédure [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication.
```
CALL mysql.rds_start_replication;
```
Après avoir établi la réplication entre votre instance de base de données MySQL source et votre cluster de bases de données Amazon Aurora, vous pouvez ajouter des réplicas Aurora à votre cluster de bases de données Amazon Aurora. Vous pouvez alors vous connecter aux réplicas Aurora pour dimensionner vos données en lecture. Pour plus d’informations sur la création d’un réplica Aurora, consultez [Ajout de réplicas Aurora à un cluster de bases de données](aurora-replicas-adding.md).
# Optimisation de la réplication des journaux binaires pour Aurora MySQL
Découvrez ci-dessous comment optimiser les performances de réplication des journaux binaires et résoudre les problèmes connexes dans Aurora MySQL.
**Astuce**
Pour continuer, il est nécessaire de connaître le mécanisme de réplication de journaux binaires MySQL et son fonctionnement. Pour en savoir plus, consultez [Replication Implementation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) dans la documentation MySQL.
## Réplication des journaux binaires multithread
Avec la réplication de journaux binaires multithreads, un thread SQL lit les événements du journal de relais et les met en file d’attente pour que les threads de travail SQL s’appliquent. Les threads de travail SQL sont gérés par un thread coordinateur. Si cela est possible, les événements du journal binaire sont appliqués en parallèle. Le niveau de parallélisme dépend de facteurs tels que la version, les paramètres, la conception du schéma et les caractéristiques de la charge de travail.
La réplication multithread des journaux binaires est prise en charge dans Aurora MySQL version 3 et dans Aurora MySQL version 2.12.1 ou ultérieure. Pour qu’un réplica multithread traite efficacement les événements du journal binaire en parallèle, vous devez configurer la source pour la réplication des journaux binaires multithread. La source doit également utiliser une version qui inclut les informations de parallélisme sur ses fichiers journaux binaires.
Lorsqu’une instance de base de données Aurora MySQL est configurée pour utiliser la réplication de journaux binaires, l’instance de réplica utilise par défaut la réplication à thread unique pour les versions d’Aurora MySQL inférieures à 3.04. Pour activer la réplication multithread, mettez à jour le paramètre `replica_parallel_workers` pour que sa valeur soit supérieure à `1` dans votre groupe de paramètres personnalisés.
Pour Aurora MySQL 3.04 et versions ultérieures, la réplication est multithread par défaut. La valeur `replica_parallel_workers` est définie sur `4`. Vous pouvez modifier ce paramètre dans votre groupe de paramètres personnalisés.
Pour augmenter la résilience de votre base de données face aux arrêts inattendus, nous vous recommandons d'activer la réplication GTID sur la source et d'autoriser GTIDs la réplication. Pour autoriser la réplication GTID, définissez `gtid_mode` sur `ON_PERMISSIVE` à la fois sur la source et le réplica. 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).
Les options de configuration suivantes vous permettent d’optimiser la réplication multithread. Pour plus d’informations, consultez [Options et variables de réplication et de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) dans le *manuel de référence MySQL*. Pour plus d’informations sur la réplication multithread, consultez le blog MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/).
Les valeurs optimales des paramètres dépendent de plusieurs facteurs. Par exemple, les performances de la réplication des journaux binaires sont influencées par les caractéristiques de charge de travail de votre base de données, ainsi que la classe d’instance de base de données sur laquelle le réplica s’exécute. Dès lors, nous vous recommandons de tester minutieusement toutes les modifications apportées à ces paramètres de configuration avant d’appliquer de nouveaux paramètres à une instance de production :
+ `binlog_format recommended value` : défini sur `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking` : la valeur recommandée est `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type` : la valeur recommandée est `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction` : la valeur recommandée est `XXHASH64`
Les caractéristiques de votre schéma et de votre charge de travail sont des facteurs qui influent sur la réplication en parallèle. Les facteurs les plus courants sont les suivants.
+ Absence de clés primaires : RDS ne peut pas établir de dépendance entre les ensembles d’écritures pour les tables dépourvues de clés primaires. Avec le format `ROW`, une seule instruction à plusieurs lignes peut être exécutée avec une seule analyse de table complète au niveau de la source, mais il en résulte une analyse de table complète par ligne modifiée sur le réplica. L’absence de clés primaires réduit considérablement le débit de réplication.
+ Présence de clés étrangères : s’il existe des clés étrangères, Amazon RDS ne peut pas utiliser la dépendance entre les ensembles d’écritures pour le parallélisme des tables avec la relation FK.
+ Taille des transactions : si une seule transaction couvre des dizaines ou des centaines de mégaoctets ou de gigaoctets, le thread coordinateur et l’un des threads de travail peuvent passer beaucoup de temps à traiter uniquement cette transaction. Pendant ce temps, tous les autres threads de travail peuvent rester inactifs une fois qu’ils terminent le traitement de leurs transactions précédentes.
Dans Aurora MySQL version 3.06 et versions ultérieures, vous pouvez améliorer les performances des réplicas de journaux binaires lors de la réplication des transactions pour de tables de grande taille comportant plusieurs index secondaires. Cette fonctionnalité introduit un groupe de threads permettant d’appliquer des modifications d’index secondaires en parallèle sur un réplica de journal binaire. Cette fonctionnalité est contrôlée par le paramètre de cluster de bases de données `aurora_binlog_replication_sec_index_parallel_workers`, qui contrôle le nombre total de threads parallèles disponibles pour appliquer les modifications d’index secondaires. Par défaut, ce paramètre est défini sur `0` (désactivé). L’activation de cette fonctionnalité ne nécessite pas le redémarrage de l’instance. Pour activer cette fonctionnalité, arrêtez la réplication en cours, définissez le nombre souhaité de threads de travail parallèles, puis relancez la réplication.
## Optimisation de la réplication des journaux binaires
Dans Aurora MySQL 2.10 et versions ultérieures, Aurora applique automatiquement une optimisation connue sous le nom de I/O cache binlog à la réplication des journaux binaires. En mettant en cache les événements de journal binaire les plus récemment validés, cette optimisation est conçue pour améliorer les performances du thread de vidage des journaux binaires tout en limitant l’impact sur les transactions de premier plan sur l’instance source des journaux binaires.
**Note**
La mémoire utilisée pour cette fonction est indépendante du paramètre `binlog_cache` de MySQL.
Cette fonction ne s’applique pas aux instances de base de données Aurora qui utilisent les classes d’instance `db.t2` et `db.t3`.
Vous n’avez pas besoin d’ajuster les paramètres de configuration pour activer cette optimisation. En particulier, si vous aviez défini le paramètre de configuration `aurora_binlog_replication_max_yield_seconds` sur une valeur différente de zéro dans des versions antérieures d’Aurora MySQL, redéfinissez-le sur zéro pour les versions actuellement disponibles.
Les variables `aurora_binlog_io_cache_reads` d'état vous `aurora_binlog_io_cache_read_requests` aident à surveiller la fréquence à laquelle les données sont lues à partir du I/O cache binlog.
+ `aurora_binlog_io_cache_read_requests`indique le nombre de demandes de I/O lecture du journal binaire depuis le cache.
+ `aurora_binlog_io_cache_reads`indique le nombre de I/O lectures du journal binaire qui extraient des informations du cache.
La requête SQL suivante calcule le pourcentage de demandes de lecture de journaux binaires qui tirent parti des informations mises en cache. Dans ce cas, plus le ratio est proche de 100, mieux c’est.
```
mysql> SELECT
(SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
/ (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
* 100
as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
| 99.99847949080622 |
+---------------------------+
```
La fonctionnalité de I/O cache binlog inclut également de nouvelles métriques liées aux threads de vidage de binlog. Les *threads de vidage* sont les threads créés lorsque de nouveaux réplicas de journaux binaires sont connectés à l’instance source des journaux binaires.
Les métriques de thread de vidage sont imprimées dans le journal de la base de données toutes les 60 secondes avec le préfixe `[Dump thread metrics]`. Les métriques incluent des informations pour chaque réplica de journal binaire, telles que `Secondary_id`, `Secondary_uuid`, le nom du fichier journal binaire et la position que chaque réplica est en train de lire. Les métriques incluent également `Bytes_behind_primary`, qui représente la distance en octets entre la source de réplication et le réplica. Cette métrique mesure le décalage du I/O thread de réplication. Cette figure est différente du décalage du thread d’application SQL du réplica, représenté par la métrique `seconds_behind_master` sur le réplica du journal binaire. Vous pouvez déterminer si les réplicas de journaux binaires rattrapent la source ou sont en retard en vérifiant si la distance diminue ou augmente.
## Journal de relais en mémoire
Dans Aurora MySQL 3.10 et versions ultérieures, Aurora introduit une optimisation connue sous le nom de « journal de relais en mémoire » afin d’améliorer le débit de réplication. Cette optimisation améliore les I/O performances des journaux de relais en mettant en cache tout le contenu des journaux de relais intermédiaires en mémoire. Par conséquent, il réduit la latence de validation en minimisant les I/O opérations de stockage puisque le contenu du journal du relais reste facilement accessible en mémoire.
Par défaut, la fonctionnalité de journal de relais en mémoire est automatiquement activée pour les scénarios de réplication gérés par Aurora (y compris les déploiements bleu-vert, la réplication Aurora/Aurora et les réplicas entre régions) lorsque le réplica répond à l’une des configurations suivantes :
+ Mode de réplication à thread unique (replica\$1parallel\$1workers = 0)
+ Réplication multithread avec le mode GTID activé :
+ Positionnement automatique activé
+ Mode GTID activé sur le réplica
+ Réplication basée sur des fichiers avec replica\$1preserve\$1commit\$1order = ON
La fonctionnalité de journal de relais en mémoire est prise en charge sur les classes d’instance supérieures à t3.large, mais n’est pas disponible sur les instances Aurora Serverless. La mémoire tampon circulaire du journal de relais a une taille fixe de 128 Mo. Pour contrôler la consommation de mémoire de cette version, vous pouvez exécuter la requête suivante :
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
La fonctionnalité de journal de relais en mémoire est contrôlée par le paramètre aurora\$1in\$1memory\$1relaylog, qui peut être défini au niveau du cluster de bases de données ou de l’instance de base de données. Vous pouvez activer ou désactiver cette version de manière dynamique sans avoir à redémarrer l’instance :
1. Arrêt de la réplication en cours
1. Définissez aurora\$1in\$1memory\$1relaylog sur ON (pour l’activer) ou OFF (pour le désactiver) dans le groupe de paramètres.
1. Redémarrage de la réplication
Exemple :
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
Même quand aurora\$1in\$1memory\$1relaylog est activé, la fonctionnalité de journal de relais en mémoire peut toujours être désactivée dans certaines conditions. Pour vérifier l’état actuel de cette fonctionnalité, vous pouvez utiliser la commande suivante :
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
Si la fonctionnalité est désactivée de façon inattendue, vous pouvez en identifier la raison en exécutant :
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
Cette commande renvoie un message expliquant pourquoi la fonctionnalité est actuellement désactivée.
# Configuration du binlog amélioré pour Aurora MySQL
Le binlog amélioré réduit la surcharge de performances de calcul provoquée par l’activation de binlog, qui peut atteindre 50 % dans certains cas. Avec le binlog amélioré, cette surcharge peut être réduite à environ 13 %. Pour réduire la surcharge, le binlog amélioré écrit les journaux binaires et de transactions sur le stockage en parallèle, ce qui minimise les données écrites au moment de la validation de la transaction.
L’utilisation d’un binlog amélioré améliore également le temps de récupération de la base de données après les redémarrages et les basculements de 99 % par rapport au binlog MySQL communautaire. Le binlog amélioré est compatible avec les charges de travail existantes basées sur binlog et vous interagissez avec lui de la même manière que vous interagissez avec le binlog MySQL communautaire.
Le binlog amélioré est disponible sur les versions Aurora MySQL 3.03.1 et ultérieures.
**Topics**
+ [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [Autres paramètres connexes](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [Différences entre le binlog amélioré et le binlog MySQL communautaire](#AuroraMySQL.Enhanced.binlog.differences)
+ [Métriques Amazon CloudWatch pour le binlog amélioré](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [Limites du binlog amélioré](#AuroraMySQL.Enhanced.binlog.limitations)
## Configuration des paramètres d’un binlog amélioré
Vous pouvez basculer entre le binlog MySQL communautaire et le binlog amélioré en activant/désactivant les paramètres du binlog amélioré. Les utilisateurs existants de binlog peuvent continuer à lire et à utiliser les fichiers binlog sans aucune interruption dans la séquence des fichiers binlog.
Pour activer le binlog amélioré, définissez les paramètres suivants :
| Paramètre | Par défaut | Description |
| --- | --- | --- |
| binlog\$1format | – | Définissez le paramètre binlog\$1format au format de journalisation binaire de votre choix pour activer le binlog amélioré. Assurez-vous que le binlog\$1format parameter n’est pas réglé sur OFF. Pour plus d’informations, consultez [Configuration de la journalisation binaire Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). |
| aurora\$1enhanced\$1binlog | 0 | Définissez la valeur de ce paramètre sur 1 dans le groupe de paramètres du cluster de bases de données associé au cluster Aurora MySQL. Lorsque vous modifiez la valeur de ce paramètre, vous devez redémarrer l’instance de rédacteur lorsque la valeur DBClusterParameterGroupStatus est affichée comme pending-reboot. |
| binlog\$1backup | 1 | Désactivez ce paramètre pour activer le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 0. |
| binlog\$1replication\$1globaldb | 1 | Désactivez ce paramètre pour activer le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 0. |
**Important**
Vous ne pouvez désactiver les paramètres `binlog_backup` et `binlog_replication_globaldb` que lorsque vous utilisez le binlog amélioré.
Pour désactiver le journal binaire amélioré, définissez les paramètres suivants :
| Paramètre | Description |
| --- | --- |
| aurora\$1enhanced\$1binlog | Définissez la valeur de ce paramètre sur 0 dans le groupe de paramètres du cluster de bases de données associé au cluster Aurora MySQL. À chaque fois que vous modifiez la valeur de ce paramètre, vous devez redémarrer l’instance de rédacteur lorsque la valeur DBClusterParameterGroupStatus est affichée comme pending-reboot. |
| binlog\$1backup | Activez ce paramètre lorsque vous désactivez le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 1. |
| binlog\$1replication\$1globaldb | Activez ce paramètre lorsque vous désactivez le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 1. |
Pour vérifier si le binlog amélioré est activé, utilisez la commande suivante dans le client MySQL :
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
Lorsque le binlog amélioré est activé, la sortie affiche `ACTIVE` pour`aurora_enhanced_binlog`.
## Autres paramètres connexes
Lorsque vous activez le binlog amélioré, les paramètres suivants sont affectés :
+ Le paramètre `max_binlog_size` est visible mais non modifiable. Sa valeur par défaut `134217728` est automatiquement ajustée sur `268435456` lorsque le binlog amélioré est activé.
+ Contrairement au binlog MySQL communautaire, `binlog_checksum` n’agit pas comme un paramètre dynamique lorsque le binlog amélioré est activé. Pour que la modification de ce paramètre soit prise en compte, vous devez redémarrer manuellement le cluster de bases de données, même si la `ApplyMethod` est `immediate`.
+ La valeur que vous définissez sur le paramètre `binlog_order_commits` n’a aucun effet sur l’ordre des validations lorsque le binlog amélioré est activé. Les validations sont toujours ordonnées sans aucune autre incidence sur les performances.
## Différences entre le binlog amélioré et le binlog MySQL communautaire
Le binlog amélioré interagit différemment avec les clones, les sauvegardes et la base de données globale Aurora par rapport au binlog MySQL communautaire. Nous vous recommandons de comprendre les différences suivantes avant d’utiliser le binlog amélioré.
+ Les fichiers binlog améliorés du cluster de bases de données source ne sont pas disponibles sur un cluster de bases de données cloné.
+ Les fichiers binlog améliorés ne sont pas inclus dans les sauvegardes Aurora. Par conséquent, les fichiers binlog améliorés du cluster de bases de données source ne sont pas disponibles après la restauration d’un cluster de bases de données, même avec une période de conservation définie.
+ Lorsqu’ils sont utilisés avec une base de données globale Aurora, les fichiers binlog améliorés du cluster de bases de données principal ne sont pas répliqués vers le cluster de bases de données des régions secondaires.
****Exemples****
Les exemples suivants montrent les différences entre le binlog amélioré et le binlog MySQL communautaire.
**Sur un cluster de bases de données restauré ou cloné**
Lorsque le binlog amélioré est activé, les fichiers binlog historiques ne sont pas disponibles dans le cluster de bases de données restauré ou cloné. Après une opération de restauration ou de clonage, si le binlog est activé, le nouveau cluster de bases de données commence à écrire sa propre séquence de fichiers binlog, en commençant par 1 (mysql-bin-changelog.000001).
Pour activer le binlog amélioré après une opération de restauration ou de clonage, définissez les paramètres du cluster de bases de données requis sur le cluster de bases de données restauré ou cloné. Pour plus d’informations, consultez [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Exemple : opération de clonage ou de restauration effectuée lorsque le binlog amélioré est activé**
Cluster de bases de données source :
```
mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Sur un cluster de bases de données restauré ou cloné, les fichiers binlog ne sont pas sauvegardés lorsque le journal binaire amélioré est activé. Pour éviter toute discontinuité dans les données du binlog, les fichiers binlog écrits avant l’activation du binlog amélioré ne sont pas non plus disponibles.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Exemple : opération de clonage ou de restauration effectuée lorsque le binlog amélioré est désactivé**
Cluster de bases de données source :
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Le journal binaire amélioré est désactivé après `mysql-bin-changelog.000003`. Sur un cluster de bases de données restauré ou cloné, les fichiers binlog écrits après la désactivation du binlog amélioré sont disponibles.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Sur une Amazon Aurora Global Database**
Sur une Amazon Aurora Global Database, les données du binlog du cluster de bases de données principal ne sont pas répliquées vers les clusters de bases de données secondaires. Après un processus de basculement entre régions, les données du binlog ne sont pas disponibles dans le cluster de bases de données principal récemment promu. Si le binlog est activé, le nouveau cluster de bases de données récemment promu commence sa propre séquence de fichiers binlog, en commençant par 1 (mysql-bin-changelog.000001).
Pour activer le binlog amélioré après un basculement, vous devez définir les paramètres de cluster de bases de données requis sur le cluster de bases de données secondaire. Pour plus d’informations, consultez [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example Exemple : l’opération de basculement global de la base de données est effectuée lorsque le binlog amélioré est activé**
Ancien cluster de bases de données principal (avant le basculement) :
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
Nouveau cluster de bases de données principal (après le basculement) :
Les fichiers binlog ne sont pas répliqués vers les régions secondaires lorsque le binlog amélioré est activé. Pour éviter toute discontinuité dans les données du binlog, les fichiers binlog écrits avant l’activation du binlog amélioré ne sont pas disponibles.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example Exemple : l’opération de basculement global de la base de données est effectuée lorsque le binlog amélioré est désactivé**
Cluster de bases de données source :
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
**Cluster de bases de données restauré ou cloné :**
Le journal binaire amélioré est désactivé après `mysql-bin-changelog.000003`. Les fichiers binlog qui sont écrits après la désactivation du binlog amélioré sont répliqués et sont disponibles dans le cluster de bases de données récemment promu.
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
```
## Métriques Amazon CloudWatch pour le binlog amélioré
Les métriques Amazon CloudWatch suivantes sont publiées uniquement lorsque le binlog amélioré est activé.
| Métrique CloudWatch | Description | Unités |
| --- | --- | --- |
| ChangeLogBytesUsed | Volume de stockage utilisé par le binlog amélioré. | Octets |
| ChangeLogReadIOPs | Nombre d’opérations d’E/S de lecture réalisées dans le binlog amélioré à 5 minutes d’intervalles. | Compte par 5 minutes |
| ChangeLogWriteIOPs | Nombre d’opérations d’E/S d’écriture disque réalisées dans le binlog amélioré à 5 minutes d’intervalles. | Compte par 5 minutes |
## Limites du binlog amélioré
Les limites suivantes s’appliquent aux clusters de bases de données Amazon Aurora lorsque le binlog amélioré est activé.
+ Le binlog amélioré est uniquement pris en charge sur les versions Aurora MySQL 3.03.1 et ultérieures.
+ Les fichiers binlog améliorés écrits sur le cluster de bases de données principal ne sont pas copiés vers les clusters de bases de données clonés ou restaurés.
+ Lorsqu’ils sont utilisés avec Amazon Aurora Global Database, les fichiers binlog améliorés du cluster de bases de données principal ne sont pas répliqués vers les clusters de bases de données secondaires. Par conséquent, après le processus de basculement, les données historiques du binlog ne sont pas disponibles dans le nouveau cluster de bases de données principal.
+ Les paramètres de configuration du binlog suivants sont ignorés :
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ Vous ne pouvez pas supprimer ou renommer une table corrompue dans une base de données. Pour supprimer ces tables, vous pouvez contacter Support.
+ Le cache d’E/S du binlog est désactivé lorsque le binlog amélioré est activé. Pour plus d’informations, consultez [Optimisation de la réplication des journaux binaires pour Aurora MySQL](binlog-optimization.md).
**Note**
Le binlog amélioré fournit de meilleures performances de lecture similaires à celles du cache d’E/S du binlog et de meilleures performances d’écriture.
+ La fonction de retour en arrière n’est pas prise en charge. Le binlog amélioré ne peut pas être activé dans un cluster de bases de données dans les conditions suivantes :
+ Cluster de bases de données avec la fonctionnalité de retour en arrière actuellement activée.
+ Cluster de bases de données avec la fonctionnalité de retour en arrière précédemment activée mais maintenant désactivée.
+ Cluster de bases de données restauré à partir d’un cluster de bases de données source ou d’un instantané avec la fonction de retour en arrière activée.