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.
# Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS
Vous pouvez créer un cluster de bases de données Amazon Aurora MySQL en tant que réplica en lecture dans une Région AWS autre que celle du cluster de bases de données source. Cette approche vous permet d’améliorer vos capacités de reprise après sinistre, de faire évoluer les opérations de lecture dans une Région AWS qui est plus proche de vos utilisateurs et de faciliter la migration d’une Région AWS à une autre.
Vous pouvez créer des réplicas en lecture pour les clusters de bases de données chiffrés et non chiffrés. Le réplica en lecture doit être chiffré si le cluster de bases de données source est chiffré.
Pour chaque cluster de bases de données source, vous pouvez avoir jusqu’à cinq clusters de bases de données entre régions qui sont des réplicas en lecture.
**Note**
Comme alternative aux réplicas en lecture entre régions, vous pouvez mettre à l’échelle les opérations de lecture avec un temps de latence minimal à l’aide d’une base de données Aurora globale. Une base de données Aurora globale a un cluster de bases de données Aurora principal dans une Région AWS, et jusqu’à 10 clusters de bases de données secondaires en lecture seule dans d’autres régions. Chaque cluster de bases de données secondaire peut inclure jusqu’à 16 réplicas Aurora (plutôt que 15). La réplication du cluster de bases de données primaire vers tous les clusters secondaires est gérée par la couche de stockage Aurora plutôt que par le moteur de base de données. Ainsi, le temps de latence de réplication des modifications est minime (généralement inférieur à 1 seconde). Exclure le moteur de base de données du processus de réplication permet de le dédier au traitement des charges de travail. En outre, vous n’avez pas besoin de configurer ou de gérer la réplication binlog (journalisation binaire) d’Aurora MySQL. Pour en savoir plus, consultez [Utilisation d’Amazon Aurora Global Database](aurora-global-database.md).
Lorsque vous créez un réplica en lecture de cluster de bases de données Aurora MySQL dans une autre Région AWS, vous devez être conscient des points suivants :
+ Votre cluster de bases de données source et votre cluster de bases de données de réplica en lecture entre régions peuvent avoir jusqu’à 15 réplicas Aurora, avec l’instance principale du cluster de bases de données. En utilisant cette fonctionnalité, vous pouvez mettre à l’échelle les opérations de lecture pour votre Région AWS source et votre Région AWS cible de réplication.
+ Dans un scénario entre régions, le retard entre le cluster de bases de données source et le réplica en lecture est plus important du fait que les canaux de réseau entre les Régions AWS sont plus longs.
+ Les données transférées pour la réplication entre régions génèrent des frais de transfert de données Amazon RDS. Les actions de réplication entre régions suivantes génèrent des frais pour les données transférées hors de la Région AWS source :
+ Lorsque vous créez le réplica en lecture, Amazon RDS prend un instantané du cluster source et transfère cet instantané vers la Région AWS où se trouve le réplica en lecture.
+ Pour chaque modification des données effectuée dans les bases de données source, Amazon RDS transfère les données de la région source vers la Région AWS où se trouve le réplica en lecture.
Pour plus d’informations sur la tarification du transfert de données Amazon RDS, consultez [Tarification Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/).
+ Vous pouvez exécuter plusieurs actions de création ou de suppression simultanées pour les réplicas en lecture qui référencent le même cluster de bases de données source. Vous devez toutefois rester dans la limite de cinq réplicas en lecture pour chaque cluster de bases de données source.
+ Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que le cluster de bases de données source. Si vous mettez à l’échelle le cluster de bases de données source, vous devez également le faire pour les réplicas en lecture.
**Topics**
+ [Avant de commencer](#AuroraMySQL.Replication.CrossRegion.Prerequisites)
+ [Création d’un cluster de bases de données de réplica en lecture entre régions pour Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Creating.md)
+ [Promotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Promote.md)
+ [Dépannage des réplicas entre régions pour Amazon Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md)
## Avant de commencer
Pour pouvoir créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions, vous devez commencer par activer la journalisation binaire sur votre cluster de bases de données Aurora MySQL source. La réplication entre régions pour Aurora MySQL utilise la réplication binaire MySQL pour relire les modifications apportées au cluster de bases de données du réplica en lecture entre régions.
Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL, mettez à jour le paramètre `binlog_format` de votre cluster de bases de données source. Le paramètre `binlog_format` est un paramètre de niveau cluster qui figure dans le groupe de paramètres de cluster par défaut. Si votre cluster de bases de données utilise le groupe de paramètres de cluster de bases de données par défaut, créez un nouveau groupe de paramètres de cluster de bases de données pour modifier les paramètres `binlog_format`. Nous vous recommandons de définir le `binlog_format` sur `MIXED`. Cependant, vous pouvez également définir `binlog_format` sur `ROW` ou `STATEMENT` si vous avez besoin d’un format binlog spécifique. Redémarrez votre cluster de bases de données Aurora pour que les modifications prennent effet.
Pour plus d’informations sur l’utilisation de la journalisation binaire Aurora, consultez [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md). Pour plus d’informations sur la modification des paramètres de configuration de Aurora MySQL, 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).
# Création d’un cluster de bases de données de réplica en lecture entre régions pour Aurora MySQL
Vous pouvez créer un cluster de bases de données Aurora en tant que réplica en lecture entre régions à l’aide de l’AWS Management Console, de l’AWS Command Line Interface (AWS CLI) ou de l’API Amazon RDS. Vous pouvez créer des réplicas en lecture entre régions à partir des clusters de bases de données chiffrés et non chiffrés.
Lorsque vous créez un réplica en lecture entre régions pour Aurora MySQL à l’aide de l’AWS Management Console, Amazon RDS crée un cluster de bases de données dans la Région AWS cible, puis crée automatiquement une instance de base de données qui est l’instance principale de ce cluster de bases de données.
Lorsque vous créez un réplica en lecture entre régions à l’aide de la AWS CLI ou de l’API RDS, vous devez commencer par créer le cluster de bases de données dans la Région AWS cible, puis attendre qu’il devienne actif. Une fois qu’il est actif, vous pouvez alors créer une instance de base de données qui est l’instance principale de ce cluster de bases de données.
La réplication commence lorsque l’instance principale du cluster de bases de données de réplica en lecture devient disponible.
Procédez comme suit pour créer un réplica en lecture entre régions à partir d’un cluster de bases de données Aurora MySQL. Ces procédures permettent de créer des réplicas en lecture à partir de clusters de bases de données chiffrés ou non chiffrés.
## Console
**Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec l’AWS Management Console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le coin supérieur droit d’AWS Management Console, sélectionnez la Région AWS qui héberge votre cluster de bases de données source.
1. Dans la panneau de navigation, choisissez **Bases de données**.
1. Sélectionnez le cluster de bases de données pour lequel vous souhaitez créer un réplica en lecture entre régions.
1. Pour **Actions**, choisissez **Create cross-Region read replica** (Créer un réplica en lecture entre régions).
1. Sur la page **Créer un réplica en lecture entre régions**, choisissez les paramètres d’option de votre cluster de bases de données de réplica en lecture entre régions, comme décrit dans le tableau suivant.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html)
1. Choisissez **Créer** pour créer votre réplica en lecture entre régions pour Aurora.
## AWS CLI
**Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec la CLI**
1. Appelez la commande AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) dans la Région AWS où vous voulez créer le cluster de bases de données de réplica en lecture. Incluez l’option `--replication-source-identifier` et indiquez l’Amazon Resource Name (ARN) du cluster de bases de données source pour lequel vous créez un réplica en lecture.
Pour une réplication entre régions où le cluster de bases de données identifié par `--replication-source-identifier` est chiffré, spécifiez les options `--kms-key-id` et `--storage-encrypted`.
**Note**
Vous pouvez configurer la réplication entre régions à partir d’un cluster de bases de données non chiffré vers un réplica en lecture chiffré en spécifiant `--storage-encrypted` et en fournissant une valeur pour l’option `--kms-key-id`.
Vous ne pouvez pas spécifier les paramètres `--master-username` et `--master-user-password`. Ces valeurs sont extraites du cluster de bases de données source.
L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données non chiffré dans la région us-west-2. La commande est appelée dans la région us-east-1. Cet exemple spécifie l’option `--manage-master-user-password` permettant de générer le mot de passe de l’utilisateur principal et de le gérer dans Secrets Manager. Pour plus d’informations, consultez [Gestion des mots de passe avec Amazon Aurora et AWS Secrets Manager](rds-secrets-manager.md). Vous pouvez également utiliser l’option `--master-password` pour spécifier et gérer vous-même le mot de passe.
Pour Linux, macOS ou Unix :
```
aws rds create-db-cluster \
--db-cluster-identifier sample-replica-cluster \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.08.0 \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster
```
Pour Windows :
```
aws rds create-db-cluster ^
--db-cluster-identifier sample-replica-cluster ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.08.0 ^
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster
```
L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données chiffré dans la région us-west-2. La commande est appelée dans la région us-east-1.
Pour Linux, macOS ou Unix :
```
aws rds create-db-cluster \
--db-cluster-identifier sample-replica-cluster \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.08.0 \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \
--kms-key-id my-us-east-1-key \
--storage-encrypted
```
Pour Windows :
```
aws rds create-db-cluster ^
--db-cluster-identifier sample-replica-cluster ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.08.0 ^
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^
--kms-key-id my-us-east-1-key ^
--storage-encrypted
```
L’option `--source-region` est obligatoire pour la réplication entre les régions AWS GovCloud (US-East) et AWS GovCloud (US-West), où le cluster de bases de données identifié par `--replication-source-identifier` est chiffré. Pour `--source-region`, spécifiez la Région AWS du cluster de bases de données source.
Si `--source-region` n’est pas spécifié, spécifiez une valeur `--pre-signed-url`. Une *URL présignée* est une URL qui contient une demande signée via Signature Version 4 pour la commande `create-db-cluster` qui est appelée dans la Région AWS source. Pour en savoir plus sur l’option `pre-signed-url`, consultez [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) dans le manuel *AWS CLI Command Reference*.
1. Vérifiez que le cluster de bases de données est disponible pour être utilisé à l’aide de la commande AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html), comme indiqué dans l’exemple suivant.
```
aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster
```
Lorsque les résultats **`describe-db-clusters`** affichent le statut `available`, créez l’instance principale pour le cluster de bases de données afin que la réplication commence. Pour ce faire, utilisez la commande AWS CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html), comme illustré dans l’exemple suivant.
Pour Linux, macOS ou Unix :
```
aws rds create-db-instance \
--db-cluster-identifier sample-replica-cluster \
--db-instance-class db.r5.large \
--db-instance-identifier sample-replica-instance \
--engine aurora-mysql
```
Pour Windows :
```
aws rds create-db-instance ^
--db-cluster-identifier sample-replica-cluster ^
--db-instance-class db.r5.large ^
--db-instance-identifier sample-replica-instance ^
--engine aurora-mysql
```
Lorsque l’instance de base de données est créée et disponible, la réplication commence. Vous pouvez déterminer si l’instance de base de données est disponible en appelant la commande AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html).
## API RDS
**Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec l’API**
1. Appelez l’opération [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de l’API RDS dans la Région AWS où vous voulez créer le cluster de bases de données de réplica en lecture. Incluez le paramètre `ReplicationSourceIdentifier` et indiquez l’Amazon Resource Name (ARN) du cluster de bases de données source pour lequel vous créez un réplica en lecture.
Pour une réplication entre régions où le cluster de bases de données identifié par `ReplicationSourceIdentifier` est chiffré, spécifiez le paramètre `KmsKeyId` et définissez le paramètre `StorageEncrypted` sur `true`.
**Note**
Vous pouvez configurer la réplication entre régions à partir d’un cluster de bases de données non chiffré vers un réplica en lecture chiffré en définissant `StorageEncrypted` sur **true** et en fournissant une valeur pour l’option `KmsKeyId`. Dans ce cas, il n’est pas nécessaire de spécifier `PreSignedUrl`.
Vous n’avez pas besoin d’inclure les paramètres `MasterUsername` et `MasterUserPassword`, parce que ces valeurs sont extraites du cluster de bases de données source.
L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données non chiffré dans la région us-west-2. L’action est appelée dans la région us-east-1.
```
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster
&DBClusterIdentifier=sample-replica-cluster
&Engine=aurora-mysql
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T001547Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7
```
L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données chiffré dans la région us-west-2. L’action est appelée dans la région us-east-1.
```
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&KmsKeyId=my-us-east-1-key
&StorageEncrypted=true
&PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F
%253FAction%253DCreateDBCluster
%2526DestinationRegion%253Dus-east-1
%2526KmsKeyId%253Dmy-us-east-1-key
%2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster
%2526SignatureMethod%253DHmacSHA256
%2526SignatureVersion%253D4
%2526Version%253D2014-10-31
%2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256
%2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request
%2526X-Amz-Date%253D20161117T215409Z
%2526X-Amz-Expires%253D3600
%2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date
%2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613
&ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster
&DBClusterIdentifier=sample-replica-cluster
&Engine=aurora-mysql
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T001547Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7
```
Pour la réplication entre les régions AWS GovCloud (US-East) et AWS GovCloud (US-West), où le cluster de bases de données identifié par `ReplicationSourceIdentifier` est chiffré, spécifiez également le paramètre `PreSignedUrl`. L’URL présignée doit être une demande valide pour l’opération d’API `CreateDBCluster`, laquelle peut être effectuée dans la Région AWS source qui contient le cluster de bases de données chiffré à répliquer. L’identifiant de clé KMS qui permet de chiffrer le réplica en lecture, qui doit être une clé KMS valide pour la Région AWS de destination. Pour générer automatiquement plutôt que manuellement une URL présignée, utilisez plutôt la commande AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) avec l’option `--source-region`.
1. Vérifiez que le cluster de bases de données est disponible pour être utilisé avec l’opération [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de l’API RDS, comme indiqué dans l’exemple suivant.
```
https://rds.us-east-1.amazonaws.com/
?Action=DescribeDBClusters
&DBClusterIdentifier=sample-replica-cluster
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T002223Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426
```
Lorsque les résultats `DescribeDBClusters` affichent le statut `available`, créez l’instance principale pour le cluster de bases de données afin que la réplication commence. Pour ce faire, utilisez l’action [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de l’API RDS, comme illustré dans l’exemple suivant.
```
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBInstance
&DBClusterIdentifier=sample-replica-cluster
&DBInstanceClass=db.r5.large
&DBInstanceIdentifier=sample-replica-instance
&Engine=aurora-mysql
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20160201T003808Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb
```
Lorsque l’instance de base de données est créée et disponible, la réplication commence. Vous pouvez déterminer si l’instance de base de données est disponible en appelant la commande AWS CLI [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html).
## Affichage des réplicas entre régions Amazon Aurora MySQL
Vous pouvez afficher les relations de réplication entre régions de vos clusters de bases de données Amazon Aurora MySQL en appelant la commande AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) ou l’opération [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de l’API RDS. Dans la réponse, reportez-vous au champ `ReadReplicaIdentifiers` pour obtenir les identifiants de cluster de bases de données de tous les clusters de bases de données de réplica en lecture entre régions. Reportez-vous à l’élément `ReplicationSourceIdentifier` pour obtenir l’ARN du cluster de bases de données source qui est la source de réplication.
# Promotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL
Vous pouvez promouvoir un réplica en lecture Aurora MySQL en cluster de bases de données autonome. Lorsque vous promouvez un réplica en lecture Aurora MySQL, les instances de base de données sont redémarrées avant de devenir disponibles.
En règle générale, vous effectuez la promotion d’un réplica en lecture Aurora MySQL en cluster de bases de données autonome comme plan de récupération des données en cas de défaillance du cluster de bases de données source.
Pour cela, commencez par créer un réplica en lecture, puis surveillez le cluster de bases de données source pour détecter les défaillances. En cas de panne, procédez comme suit :
1. Promouvez le réplica en lecture.
1. Dirigez le trafic de base de données vers le cluster de bases de données promu.
1. Créez un réplica en lecture de remplacement en utilisant le cluster de bases de données promu comme source.
Lorsque vous effectuez la promotion d’un réplica en lecture, celui-ci devient un cluster de bases de données Aurora autonome. Le processus de promotion peut prendre plusieurs minutes ou plus longtemps, selon la taille du réplica en lecture. Une fois le réplica en lecture promu en nouveau cluster de bases de données, il est similaire à tout autre cluster de bases de données. Par exemple, vous pouvez créer des réplicas en lecture à partir de celui-ci et effectuer des opérations de restauration à un moment donné. Vous pouvez également créer des réplicas Aurora pour le cluster de bases de données.
Étant donné que le cluster de bases de données promu n’est plus un réplica en lecture, vous ne pouvez pas l’utiliser comme cible de réplication.
Les étapes suivantes décrivent le processus général de promotion d’un réplica en lecture en cluster de bases de données :
1. Arrêtez l’écriture de toute transaction sur le cluster de bases de données source du réplica en lecture, puis attendez que toutes les mises à jour soient terminées sur le réplica en lecture. Les mises à jour de la base de données ont lieu sur les réplicas en lecture après avoir eu lieu sur le cluster de bases de données source, et cette latence de réplication peut varier de façon significative. Utilisez la métrique `ReplicaLag` pour déterminer à quel moment toutes les mises à jour ont été effectuées sur le réplica en lecture. La métrique `ReplicaLag` enregistre la durée pendant laquelle une instance de base de données de réplica en lecture retarde l’instance de base de données source. Lorsque la métrique `ReplicaLag` atteint `0`, le réplica en lecture a rattrapé l’instance de base de données source.
1. Promouvez le réplica en lecture à l’aide de l’option **Promote** (Promouvoir) sur la console Amazon RDS, de la commande AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) ou de l’opération [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) de l’API Amazon RDS.
Vous choisissez une instance de base de données Aurora MySQL pour promouvoir le réplica en lecture. Une fois le réplica en lecture promu, le cluster de bases de données Aurora MySQL est promu en cluster de bases de données autonome. L’instance de base de données ayant la priorité de basculement la plus élevée est promue en instance de base de données pour le cluster de bases de données. Les autres instances de base de données deviennent des réplicas Aurora.
**Note**
Le processus de promotion dure quelques minutes. Lorsque vous promouvez un réplica en lecture, la réplication est arrêtée et les instances de base de données sont redémarrées. Une fois le redémarrage terminé, le réplica en lecture est disponible en tant que nouveau cluster de bases de données.
## Console
**Pour promouvoir un réplica en lecture Aurora MySQL en cluster de bases de données**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans la console, choisissez **Instances**.
Le panneau **Instance** s’affiche.
1. Dans le panneau **Instances**, choisissez le réplica en lecture que vous souhaitez promouvoir.
Les réplicas en lecture apparaissent comme instances de base de données Aurora MySQL.
1. Sous **Actions**, choisissez **Promouvoir le réplica en lecture**.
1. Dans la page de confirmation, sélectionnez **Promote read replica (Promouvoir le réplica en lecture)**.
## AWS CLI
Pour promouvoir un réplica en lecture en cluster de bases de données, utilisez la commande AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html).
**Example**
Pour Linux, macOS ou Unix :
```
aws rds promote-read-replica-db-cluster \
--db-cluster-identifier mydbcluster
```
Pour Windows :
```
aws rds promote-read-replica-db-cluster ^
--db-cluster-identifier mydbcluster
```
## API RDS
Pour promouvoir un réplica en lecture en cluster de bases de données, appelez [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html).
# Dépannage des réplicas entre régions pour Amazon Aurora MySQL
La liste ci-dessous répertorie les messages d’erreur courants que vous pouvez rencontrer lors de la création d’un réplica en lecture entre régions Amazon Aurora et indique comment les résoudre.
## Source cluster [DB cluster ARN] doesn’t have binlogs enabled
Pour résoudre ce problème, activez la journalisation binaire sur le cluster de bases de données source. Pour plus d’informations, consultez [Avant de commencer](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites).
## Source cluster [DB cluster ARN] doesn’t have cluster parameter group in sync on writer
Vous recevez cette erreur si vous avez mis à jour le paramètre du cluster de bases de données `binlog_format` sans redémarrer l’instance principale du cluster de bases de données. Redémarrez l’instance principale (c’est-à-dire, l’auteur) du cluster de bases de données, puis réessayez.
## Source cluster [DB cluster ARN] already has a read replica in this region
Vous pouvez avoir jusqu’à cinq clusters de bases de données inter-régions constituant des réplicas en lecture pour chaque cluster de bases de données source dans n’importe quelle Région AWS. Si vous disposez déjà du nombre maximal de réplicas en lecture pour un cluster de bases de données dans une Région AWS particulière, vous devez supprimer un cluster existant avant de pouvoir créer un cluster de bases de données inter-régions dans cette région.
## DB cluster [DB cluster ARN] requires a database engine upgrade for cross-region replication support (Le cluster de bases de données [ARN du cluster de bases de données] nécessite une mise à jour du moteur de base de données pour la prise en charge de la réplication entre régions)
Pour résoudre ce problème, mettez à niveau la version du moteur de base de données pour toutes les instances du cluster de bases de données source vers la version de moteur de base de données la plus récente, puis réessayez de créer une base de données de réplica en lecture entre régions.