Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Amazon DocumentDB Haute disponibilité et réplication
Vous pouvez obtenir une haute disponibilité et un dimensionnement de lecture dans Amazon DocumentDB (avec compatibilité avec MongoDB) en utilisant des instances de réplication. Un seul cluster Amazon DocumentDB prend en charge une seule instance principale et jusqu'à 15 instances de réplication. Ces instances peuvent être réparties sur les différentes zones de disponibilité au sein de la région du cluster. L'instance principale accepte le trafic en lecture et en écriture et les instances de réplica acceptent uniquement les demandes en lecture.
Le volume de cluster est composé de plusieurs copies des données du cluster. Toutefois, les données du volume du cluster sont représentées sous la forme d'un volume logique unique pour l'instance principale et pour les répliques Amazon DocumentDB du cluster. Les instances de réplica sont cohérentes à terme. Elles renvoient les mêmes données pour les résultats des requêtes avec un retard de réplica minimal, généralement inférieur à 100 ms après l'écriture d'une mise à jour par l'instance principale. Le retard de réplica varie en fonction de la fréquence de modification de la base de données. Autrement dit, pendant les périodes où une importante quantité d'opérations d'écriture se produit pour la base de données, il se peut que vous constatiez un retard accru du réplica.
## Dimensionnement en lecture
Les répliques Amazon DocumentDB fonctionnent bien pour le dimensionnement des lectures, car elles sont entièrement dédiées aux opérations de lecture sur votre volume de cluster. Les opérations d'écriture sont gérées par l'instance principale. Le volume du cluster est partagé entre toutes les instances de votre cluster. Par conséquent, il n'est pas nécessaire de répliquer et de conserver une copie des données pour chaque réplique Amazon DocumentDB.
## Haute disponibilité
Lorsque vous créez un cluster Amazon DocumentDB, en fonction du nombre de zones de disponibilité dans le groupe de sous-réseaux (il doit y en avoir au moins deux), Amazon DocumentDB approvisionne les instances dans les zones de disponibilité. Lorsque vous créez des instances dans le cluster, Amazon DocumentDB distribue automatiquement les instances entre les zones de disponibilité d'un groupe de sous-réseaux afin d'équilibrer le cluster. Cette action évite également que toutes les instances soient situées dans la même zone de disponibilité.
**exemple**
Pour illustrer ce point, prenons un exemple dans lequel vous créez un cluster doté d'un groupe de sous-réseaux avec trois zones de disponibilité : *AZ1*AZ2**, et *AZ3*.
Une fois la première instance du cluster créée, elle devient l'instance principale et elle est située dans l'une des zones de disponibilité. Dans cet exemple, c'est dans *AZ1*. La deuxième instance créée est une instance de réplique située dans l'une des deux autres zones de disponibilité, par exemple *AZ2*. La troisième instance créée est une instance de réplique située dans la zone de disponibilité restante, *AZ3*. Si vous créez plusieurs instances, elles sont réparties entre les zones de disponibilité afin d'équilibrer le cluster.
Si une défaillance survient dans l'instance principale (AZ1), un basculement est déclenché et l'une des répliques existantes est promue en instance principale. Lorsque l'ancien serveur principal est rétabli, il devient une réplique dans la même zone de disponibilité que celle dans laquelle il a été approvisionné ()AZ1. Lorsque vous provisionnez un cluster à trois instances, Amazon DocumentDB continue de préserver ce cluster à trois instances. Amazon DocumentDB gère automatiquement la détection, le basculement et la restauration des défaillances d'instance sans aucune intervention manuelle.
Lorsqu'Amazon DocumentDB effectue un basculement et récupère une instance, l'instance récupérée reste dans la zone de disponibilité dans laquelle elle a été initialement mise en service. Toutefois, le rôle de l'instance peut changer, l'instance principale devenant instance de réplica. Cette opération permet d'éviter le scénario où une série de basculements entraîne la présence de toutes les instances dans la même zone de disponibilité.
Vous pouvez spécifier des répliques Amazon DocumentDB comme cibles de basculement. En d'autres termes, si l'instance principale échoue, la réplique Amazon DocumentDB spécifiée ou la réplique d'un niveau est promue vers l'instance principale. Il y a une brève interruption, pendant laquelle les demandes de lecture et d'écriture adressées à l'instance principale échouent en renvoyant une exception. Si votre cluster Amazon DocumentDB n'inclut aucune réplique Amazon DocumentDB, lorsque l'instance principale échoue, elle est recréée. La promotion d'une réplique Amazon DocumentDB est beaucoup plus rapide que la recréation de l'instance principale.
Pour les scénarios de haute disponibilité, nous vous recommandons de créer une ou plusieurs répliques Amazon DocumentDB. Ces répliques doivent appartenir à la même classe d'instance que l'instance principale et se trouver dans des zones de disponibilité différentes pour votre cluster Amazon DocumentDB.
Pour plus d’informations, consultez les ressources suivantes :
+ [Comprendre la tolérance aux pannes des clusters Amazon DocumentDB](db-cluster-fault-tolerance.md)
+ [Basculement d'Amazon DocumentDB](failover.md)
+ [Contrôle de la cible de basculement](failover.md#failover-target_control)
### Haute disponibilité grâce aux clusters mondiaux
Pour une haute disponibilité sur plusieurs sites Régions AWS, vous pouvez configurer des clusters [globaux Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). Chaque cluster mondial couvre plusieurs régions, ce qui permet des lectures globales à faible latence et une reprise après sinistre après des pannes survenant sur un. Région AWS Amazon DocumentDB gère automatiquement la réplication de toutes les données et mises à jour de la région principale vers chacune des régions secondaires.
## Ajout de réplicas
La première instance ajoutée au cluster est l'instance principale. Chaque instance ajoutée après la première instance est une instance de réplica. Un cluster peut comporter jusqu'à 15 instances de réplication en plus de l'instance principale.
Lorsque vous créez un cluster à l'aide du AWS Management Console, une instance principale est automatiquement créée en même temps. Pour créer un réplica en même temps que vous créez le cluster et l'instance principale, choisissez **Créer un réplica dans différentes zones**. Pour plus d'informations, consultez l'étape 4.d dans [Création d'un cluster Amazon DocumentDB](db-cluster-create.md). Pour ajouter d'autres répliques à un cluster Amazon DocumentDB, consultez. [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md)
Lorsque vous utilisez le AWS CLI pour créer votre cluster, vous devez créer explicitement vos instances principales et répliques. Pour plus d'informations, consultez la section « Utilisation du AWS CLI » dans les rubriques suivantes :
+ [Création d'un cluster Amazon DocumentDB](db-cluster-create.md)
+ [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md)
# Basculement d'Amazon DocumentDB
Dans certains cas, tels que certains types de maintenance planifiée, ou dans le cas peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité, Amazon DocumentDB (compatible avec MongoDB) détecte la panne et remplace le nœud principal. Au cours d'un basculement, le délai d'écriture est réduit. En effet, le rôle du nœud principal est transféré à l'un des réplicas en lecture et il n'est pas nécessaire de créer et d'allouer un nouveau nœud principal. La détection d'un échec ou la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.
Pour que le basculement fonctionne, votre cluster doit comporter au moins deux instances : une instance principale et au moins une instance de réplication.
**Note**
Cette rubrique s'applique uniquement aux clusters originaux basés sur des instances Amazon DocumentDB. Elle ne s'applique pas aux clusters élastiques ou globaux.
## Contrôle de la cible de basculement
Amazon DocumentDB vous fournit des niveaux de basculement afin de contrôler quelle instance de réplique est promue en instance principale en cas de basculement.
**Niveaux de basculement**
Chaque instance de réplique est associée à un niveau de basculement (0 à 15). Lorsqu'un basculement survient en raison d'une maintenance ou d'une défaillance matérielle peu probable, l'instance principale bascule vers une réplique ayant la priorité la plus élevée (le niveau numéroté le plus bas). Si plusieurs répliques ont le même niveau de priorité, le niveau principal bascule vers le réplica de ce niveau dont la taille est la plus proche de celle du niveau principal précédent.
En définissant le niveau de basculement pour un groupe de réplicas sélectionnés pour `0` (la priorité la plus haute), vous pouvez vous assurer qu'un basculement promeut l'un des réplicas dans ce groupe. Une manière efficace d'empêcher que des réplicas spécifiques ne soient promus en principal en cas de basculement consiste à leur attribuer un niveau de priorité faible (chiffre élevé). Cela s'avère utile dans les cas où les réplicas spécifiques font l'objet d'une utilisation intensive de la part d'une application et le basculement vers l'un d'entre eux pourrait avoir un impact négatif sur une application critique.
Vous pouvez définir le niveau de basculement d'une instance lorsque vous la créez ou plus tard en la modifiant. Le définition d'un niveau de basculement d'une instance en modifiant cette dernière ne déclenche pas un basculement. Pour plus d'informations, consultez les rubriques suivantes :
+ [Ajouter une instance Amazon DocumentDB à un cluster](db-instance-add.md)
+ [Modification d'une instance Amazon DocumentDB](db-instance-modify.md)
Lorsque vous lancez manuellement un basculement, vous avez deux moyens de contrôler quelle instance de réplica est promue en instance principale : le niveau de basculement comme décrit précédemment, et le paramètre `--target-db-instance-identifier`.
**--`target-db-instance-identifier`**
Pour le test, vous pouvez forcer un événement de basculement à l'aide de l'opération `failover-db-cluster`. Vous pouvez utiliser le paramètre `--target-db-instance-identifier` pour spécifier le réplica à promouvoir en réplica principal. L'utilisation du paramètre `--target-db-instance-identifier` remplace le niveau de priorité de basculement. Si vous ne spécifiez pas le paramètre `--target-db-instance-identifier`, le basculement principal est conforme au niveau de priorité de basculement.
## Que se passe-t-il lors d'un basculement
Le basculement est automatiquement géré par Amazon DocumentDB afin que vos applications puissent reprendre les opérations de base de données le plus rapidement possible sans intervention administrative.
+ Si vous avez une instance de réplique Amazon DocumentDB dans la même zone de disponibilité ou dans une autre zone de disponibilité en cas de basculement : Amazon DocumentDB renverse le nom canonique (CNAME) de votre instance pour qu'il pointe vers la réplique saine, qui est à son tour promue pour devenir la nouvelle instance principale. Le basculement complet s'effectue généralement en 30 secondes.
+ Si vous ne possédez pas d'instance de réplique Amazon DocumentDB (par exemple, un cluster d'instances unique) : Amazon DocumentDB tentera de créer une nouvelle instance dans la même zone de disponibilité que l'instance d'origine. Ce remplacement de l'instance d'origine s'effectue de manière optimale et peut échouer si, par exemple, un problème affecte de manière générale la zone de disponibilité.
Votre application devrait tenter une nouvelle connexion à la base de données dans le cas d'une perte de connexion.
## Test du basculement
En cas de basculement d'un cluster, l'une des répliques Amazon DocumentDB (instances en lecture seule) du cluster devient l'instance principale (le rédacteur du cluster).
Lorsque l'instance principale échoue, Amazon DocumentDB bascule automatiquement vers une réplique Amazon DocumentDB, s'il en existe une. Vous pouvez forcer un basculement lorsque vous souhaitez simuler un échec d'une instance principale à des fins de test. Chaque instance d'un cluster possède sa propre adresse de point de terminaison. Vous devez donc nettoyer et rétablir toutes les connexions existantes qui utilisent ces adresses de point de terminaison lorsque le basculement est effectué.
Pour forcer un basculement, utilisez l'opération `failover-db-cluster` avec ces paramètres.
+ `--db-cluster-identifier` : obligatoire. Nom du cluster qui doit basculer.
+ `--target-db-instance-identifier`—Facultatif. Le nom de l'instance à promouvoir comme instance principale.
**Example**
L'opération suivante force un basculement du cluster `sample-cluster`. Il ne précise pas quelle instance doit être créée comme nouvelle instance principale. Amazon DocumentDB choisit donc l'instance en fonction de la priorité du niveau de basculement.
Pour Linux, macOS ou Unix :
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster
```
Pour Windows :
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster
```
L'opération suivante force un basculement du cluster `sample-cluster`, en spécifiant quelle `sample-cluster-instance` est à promouvoir en tant que rôle principal. (Notez la valeur `"IsClusterWriter": true` dans la sortie).
Pour Linux, macOS ou Unix :
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-cluster-instance
```
Pour Windows :
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster ^
--target-db-instance-identifier sample-cluster-instance
```
La sortie de cette opération ressemble à ceci (format JSON).
```
{
"DBCluster": {
"HostedZoneId": "Z2SUY0A1719RZT",
"Port": 27017,
"EngineVersion": "3.6.0",
"PreferredMaintenanceWindow": "thu:04:05-thu:04:35",
"BackupRetentionPeriod": 1,
"ClusterCreateTime": "2018-06-28T18:53:29.455Z",
"AssociatedRoles": [],
"DBSubnetGroup": "default",
"MasterUsername": "master-user",
"Engine": "docdb",
"ReadReplicaIdentifiers": [],
"EarliestRestorableTime": "2018-08-21T00:04:10.546Z",
"DBClusterIdentifier": "sample-cluster",
"ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "sample-cluster-instance",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": true
},
{
"DBInstanceIdentifier": "sample-cluster-instance-00",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
},
{
"DBInstanceIdentifier": "sample-cluster-instance-01",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
}
],
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1a"
],
"DBClusterParameterGroup": "default.docdb3.6",
"Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"IAMDatabaseAuthenticationEnabled": false,
"AllocatedStorage": 1,
"LatestRestorableTime": "2018-08-22T21:57:33.904Z",
"PreferredBackupWindow": "00:00-00:30",
"StorageEncrypted": false,
"MultiAZ": true,
"Status": "available",
"DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-12345678"
}
],
"DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ"
}
}
```
## Décalage de réplication
Le délai de réplication est généralement de 50 ms ou moins. Les raisons les plus courantes de l'augmentation du délai de réplication sont les suivantes :
+ Un taux d'écriture élevé sur le primaire qui fait que les répliques de lecture prennent du retard par rapport au principal.
+ Conflit sur les répliques en lecture entre les requêtes de longue durée (par exemple, les scans séquentiels volumineux, les requêtes d'agrégation) et la réplication en écriture entrante.
+ Très grand nombre de requêtes simultanées sur les répliques lues.
Pour minimiser le délai de réplication, essayez les techniques de résolution des problèmes suivantes :
+ Si votre taux d'écriture ou votre taux d'utilisation du processeur est élevé, nous vous recommandons d'augmenter le nombre d'instances de votre cluster.
+ Si vos répliques en lecture comportent des requêtes de longue durée et si les documents sont fréquemment mis à jour, pensez à modifier vos requêtes de longue durée ou à les exécuter par rapport à la réplique principale/d'écriture pour éviter tout conflit sur les répliques en lecture.
+ En cas de très grand nombre de requêtes simultanées ou d'utilisation élevée du processeur uniquement sur les répliques en lecture, une autre option consiste à augmenter le nombre de répliques en lecture afin de répartir la charge de travail.
+ Le retard de réplication étant le résultat d'un débit d'écriture élevé et de requêtes de longue durée, nous vous recommandons de résoudre ce problème en utilisant la métrique DBCluster ReplicaLagMaximum CW en combinaison avec l'enregistreur de requêtes lent et `WriteThroughput` les métriques/. `WriteIOPS`
En général, nous recommandons que toutes vos répliques soient du même type d'instance, afin qu'un basculement du cluster n'entraîne pas de dégradation des performances.
Si vous choisissez entre une mise à l'échelle supérieure ou une extension externe (par exemple, six instances plus petites contre trois instances plus grandes), nous vous recommandons généralement d'essayer d'abord de procéder à une mise à l'échelle (instances plus grandes) avant de procéder à une mise à l'échelle externe, car vous obtiendrez un cache tampon plus important par instance de base de données.
De manière proactive, vous devez définir une alarme de retard de réplication et définir son seuil à une valeur que vous considérez comme la limite supérieure du retard (ou « périmé ») de vos données sur les instances de réplication avant que cela ne commence à affecter les fonctionnalités de votre application. En général, nous conseillons de dépasser le seuil de délai de réplication pour plusieurs points de données avant de déclencher une alarme, en raison de charges de travail transitoires.
**Note**
En outre, nous vous recommandons de définir une autre alarme pour les délais de réplication supérieurs à 10 secondes. Si vous dépassez ce seuil pour plusieurs points de données, nous vous recommandons d'augmenter le volume de vos instances ou de réduire le débit d'écriture sur l'instance principale.