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.
# 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.