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 : + Activez les sauvegardes automatiques de l’instance de base de données. Vous pouvez activer les sauvegardes automatiques lorsque vous créez une instance de base de données ou vous pouvez activer les sauvegardes en modifiant une instance de base de données existante. Pour plus d’informations, consultez [Création d’une instance de base de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html) dans le *Guide de l’utilisateur Amazon RDS*.
+ Créez un réplica en lecture pour l’instance de base de données. Pour plus d’informations, consultez [Utilisation des réplicas en lecture](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) dans le *Guide de l’utilisateur Amazon RDS*. | | 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 : + Le protocole SSL doit être activé sur la base de données source MySQL externe.
+ Une clé client et un certificat client doivent être préparés pour le cluster de bases de données Aurora MySQL.
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. 1. Vérifiez bien que vous êtes prêt à procéder à la réplication chiffrée : Si le protocole SSL n’est pas activé sur la base de données source MySQL externe et que vous ne disposez pas d’une clé client et d’un certificat client prêts, activez le protocole SSL sur le serveur de base de données MySQL et générez la clé client et le certificat client requis. Si le protocole SSL est activé sur la base de données source externe, fournissez une clé et un certificat client pour le cluster de bases de données Aurora MySQL. En leur absence, générez une nouvelle clé et un nouveau certificat pour le cluster de bases de données Aurora MySQL. Pour signer le certificat client, vous devez disposer de la clé d’autorité de certification utilisée pour configurer le protocole SSL sur la base de données source MySQL externe.
Pour plus d’informations, consultez [Création de certificats et clés SSL à l’aide d’openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) dans la documentation MySQL.
Vous avez besoin du certificat de l’autorité de certification, de la clé client et du certificat client.
2. Connectez-vous au cluster de bases de données Aurora MySQL en tant qu’utilisateur principal à l’aide du protocole SSL.
Pour plus d’informations sur la connexion à un cluster de bases de données Aurora MySQL avec le protocole SSL, consultez [Connexions TLS aux clusters de bases de données Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
3. Exécutez la procédure stockée `mysql.rds_import_binlog_ssl_material` pour importer les informations SSL dans le cluster de bases de données Aurora MySQL.
Pour le paramètre `ssl_material_value`, insérez les informations des fichiers au format .pem pour le cluster de bases de données Aurora MySQL dans les données utiles JSON correctes.
L’exemple suivant importe des informations SSL dans un cluster de bases de données Aurora MySQL. Dans les fichiers au format .pem, le code du corps est généralement plus long que le code du corps affiché dans l’exemple. 
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

Pour plus d’informations, consultez [mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) et [Connexions TLS aux clusters de bases de données Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). Après l’exécution de la procédure, les secrets sont stockés dans les fichiers. Pour supprimer les fichiers ultérieurement, vous pouvez exécuter la procédure stockée [mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material).
**Pour activer la journalisation binaire sur une base de données MySQL externe** 1. Depuis un shell de commande, arrêtez le service mysql. 
sudo service mysqld stop

2. Modifiez le fichier `my.cnf` (qui 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.
Si la réplication chiffrée n’est pas obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec les journaux binaires activés et le protocole SSL désactivé.
Les entrées correspondantes du fichier `/etc/my.cnf` pour les données non chiffrées sont les suivantes. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Si la réplication chiffrée est obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec le protocole SSL et les journaux binaires activés.
Les entrées du fichier `/etc/my.cnf` incluent les emplacements de fichier .pem pour le serveur de base de données MySQL. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

En outre, l’option `sql_mode` de votre instance de base de données MySQL doit être définie avec la valeur 0 ou ne pas être incluse dans votre fichier my.cnf.
Une fois connecté à la base de données MySQL externe, enregistrez la position du journal binaire de la base de données MySQL externe. 
mysql> SHOW MASTER STATUS;

Votre sortie doit ressembler à ce qui suit : 
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Pour plus d’informations, consultez [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) dans la documentation MySQL.
3. Démarrez le service mysql. 
sudo service mysqld start
| ## 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\_set\_configuration](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\_stop\_replication](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 :+ Restaurez un instantané de cluster de bases de données : Créez un instantané de cluster de bases de données de votre cluster de bases de données Amazon Aurora. Pour plus d’informations, consultez [Création d’un instantané de cluster de bases de données](USER_CreateSnapshotCluster.md). Créez un cluster de bases de données Aurora en procédant à une restauration à partir de l’instantané de cluster de bases de données que vous venez de créer.
Veillez bien à conserver le même groupe de paramètres de base de données pour votre cluster de bases de données restauré que pour votre cluster de bases de données original. Ceci vous garantit que la journalisation binaire est activée pour la copie de votre cluster de bases de données. Pour plus d’informations, consultez [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md).
+ Clonez votre 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).
**Pour déterminer le nom et la position du fichier binlog**
Utilisez l’une des méthodes suivantes :+ Dans le Console de gestion AWS : Choisissez **Bases de données**, puis choisissez l’instance principale (enregistreur) de votre nouveau cluster de bases de données Aurora afin d’en afficher les détails. Faites défiler l’écran jusqu’à **Événements récents**. Un message d’événement s’affiche pour indiquer le nom et la position du fichier journal binaire. Ce message d’événement est au format suivant. 
Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}
Enregistrez le nom et la position du fichier journal binaire lorsque vous commencez la réplication.
+ Appelez la AWS CLI commande [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html), comme dans l'exemple suivant. 
aws rds describe-events

{
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

+ Vérifiez dans le journal des erreurs MySQL la dernière position du fichier binlog MySQL.
**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.1. Connectez-vous à votre cluster de bases de données à l’aide d’un client MySQL.
2. Émettez la commande `mysqldump`. Par exemple : 
PROMPT> mysqldump --databases {{database_name}} --single-transaction
--order-by-primary -r backup.sql -u {{local_user}}s -p

3. Une fois le fichier de vidage créé, vous pouvez supprimer la copie du cluster de bases de données. | | 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*. 1. Connectez-vous à votre réplica en lecture et arrêtez la réplication en exécutant la procédure [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication).
2. Une fois le réplica en lecture **arrêté**, connectez-vous à ce réplica et exécutez la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3). Extrayez le nom du fichier journal binaire actif du champ `Relay_Master_Log_File` et la position du fichier journal du champ `Exec_Master_Log_Pos`. Enregistrez ces valeurs lorsque vous démarrez la réplication.
3. Pendant que le réplica en lecture reste à l’état **Arrêté**, créez un instantané de base de données du réplica en lecture. Pour plus d’informations, consultez [Création d’un instantané de base de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) dans le *Guide de l’utilisateur Amazon Relational Database Service*.
4. Supprimez le réplica en lecture. | | MySQL (externe) | **Pour créer un vidage d’une base de données MySQL externe**1. Avant de créer un vidage, vous devez vous assurer que l’emplacement du journal binaire du vidage est à jour avec les données de votre instance source. Pour ce faire, vous devez d’abord arrêter toutes les opérations d’écriture sur l’instance avec la commande suivante : 
mysql> FLUSH TABLES WITH READ LOCK;

2. Créez un vidage de votre base de données MySQL à l’aide de la commande `mysqldump` comme illustré ci-après : 
PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u {{local_user}} -p

3. Après avoir créé le vidage, déverrouillez les tables de votre base de données MySQL avec la commande suivante : 
mysql> UNLOCK TABLES;
| ## 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** 1. Copiez la sortie de la commande `mysqldump` de votre source de réplication vers un emplacement qui peut aussi se connecter à votre cluster de bases de données Aurora MySQL.
2. Connectez-vous à votre cluster de bases de données Aurora MySQL à l’aide de la commande `mysql`. Voici un exemple de. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. À l’invite de commande `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans le cluster de bases de données Aurora MySQL, par exemple : 
mysql> source backup.sql;
| | RDS for MySQL | **Pour charger un vidage dans une instance de base de données Amazon RDS**1. Copiez la sortie de la commande `mysqldump` depuis votre source de réplication vers un emplacement qui peut aussi se connecter à votre instance de base de données MySQL.
2. Connectez-vous à votre instance de base de données MySQL à l’aide de la commande `mysql`. Voici un exemple de. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. A l’invite de commande `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans l’instance de base de données MySQL, par exemple : 
mysql> source backup.sql;
| | 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`.1. Copiez la sortie de la commande `mysqldump` depuis votre source de réplication vers un emplacement qui peut aussi se connecter à votre base de données MySQL.
2. Connectez-vous à votre base de données MySQL à l’aide de la commande `mysql`. Voici un exemple de. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. À l’invite de commande `mysql`, exécutez la commande `source` et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans votre base de données MySQL. Voici un exemple de. 
mysql> source backup.sql;
| ## 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\_name\_resolve](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** 1. Trouvez le point de départ de la réplication. Vous avez besoin du nom du fichier journal binaire et de la position du journal binaire.
Si la cible de réplication de votre cluster de bases de données a été créée à partir de ce qui suit : Instantané du cluster de bases de données ou clone : récupérez le nom et la position du fichier binlog à partir des événements récents de votre nouveau cluster de bases de données, comme indiqué dans [3. Créer une copie ou un vidage de votre source de réplication](#AuroraMySQL.Replication.MySQL.CreateSnapshot). Instantané de la base de données : vous avez extrait le nom et la position du fichier de journal binaire à partir de la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication.
2. Connectez-vous au cluster de bases de données et exécutez les procédures suivantes pour démarrer la réplication avec votre source de réplication à l’aide du nom du fichier journal binaire et de l’emplacement de l’étape précédente : [mysql.rds\_set\_external\_source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\_set\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) (toutes les versions)
L’exemple suivant concerne Aurora MySQL version 3. 
CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

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** 1. Si votre cible de réplica d’instance de base de données a été créé à partir d’un instantané de base de données, vous avez besoin du fichier journal binaire et de la position du journal binaire qui sont le point de départ de la réplication. Vous avez extrait ces valeurs à partir de la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication.
2. Connectez-vous à l’instance de base de données et appelez les procédures [mysql.rds\_set\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\_set\_external\_source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) et [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication avec votre source de réplication. Utilisez le nom du fichier journal binaire et l’emplacement à partir de l’étape précédente. Voici un exemple. 
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

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** 1. Extrayez le fichier journal binaire et la position du journal binaire qui sont le point de départ de la réplication. Vous avez extrait ces valeurs à partir de la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication. Si votre cible de réplica MySQL externe a été renseignée à partir de la sortie de la commande `mysqldump` avec l’option `--master-data=2`, le fichier journal binaire et la position du journal binaire sont inclus dans la sortie. Voici un exemple. 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

2. Connectez-vous à la cible de réplica MySQL externe et exécutez `CHANGE MASTER TO` et `START SLAVE` (Aurora MySQL version 2) ou `START REPLICA` (Aurora MySQL version 3) pour démarrer la réplication avec votre source de réplication à l’aide du nom du fichier journal binaire et de l’emplacement de l’étape précédente, par exemple : 
CHANGE MASTER TO
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 2
START REPLICA; -- Aurora MySQL version 3
| 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\_reset\_external\_master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ou [mysql.rds\_reset\_external\_source (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\_start\_replication\_until(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\_start\_replication\_until(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 GTID-based la réplication, utilisez la procédure [mysql.rds\_start\_replication\_until\_gtid (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) stockée au lieu de la procédure [mysql.rds\_start\_replication\_until(Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) stockée. Pour plus d'informations sur GTID-based la réplication, consultez[Utilisation de GTID-based la réplication](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 Console de gestion AWS 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.