Haute disponibilité et réplication d'Amazon DocumentDB

Vous pouvez obtenir une haute disponibilité et une évolutivité de la 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. Cependant, 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 la mise à l'échelle de la lecture, car elles sont entièrement dédiées aux opérations de lecture sur le volume de votre 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. Il n'est donc 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é du groupe de sous-réseaux (il doit y en avoir au moins deux), Amazon DocumentDB provisionne des instances dans les zones de disponibilité. Lorsque vous créez des instances dans le cluster, Amazon DocumentDB distribue automatiquement les instances dans 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 cet exemple, imaginons que nous créons un cluster avec un groupe de sous-réseaux comportant 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, il s'agit de la zone AZ1. La deuxième instance créée est une instance de réplica située dans l'une des deux autres zones de disponibilité, AZ2 dans notre exemple. La troisième instance créée est une instance de réplica 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.

En cas de défaillance dans l'instance principale (AZ1), un basculement est déclenché et l'une des instances de réplica existantes est promue instance principale. Lorsque l'ancienne instance principale récupère, elle devient un réplica dans la zone de disponibilité dans laquelle elle a été mise en service (AZ1). Lorsque vous provisionnez un cluster de trois instances, Amazon DocumentDB continue de préserver ce cluster de 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 restaure une instance, l'instance récupérée reste dans la zone de disponibilité dans laquelle elle a été initialement provisionnée. 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 au rang d'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'un réplica Amazon DocumentDB est beaucoup plus rapide que la recréation de l'instance principale.

Pour une haute disponibilité, créez une ou plusieurs répliques Amazon DocumentDB de la même classe d'instance que l'instance principale dans différentes zones de disponibilité.

Pour plus d’informations, consultez les ressources suivantes :

• Comprendre la tolérance aux pannes des clusters Amazon DocumentDB

• Basculement d'Amazon DocumentDB

  • Contrôle de la cible de basculement

Dans les versions 5.0 et 8.0 d'Amazon DocumentDB, les instances de réplication ne redémarrent pas lorsque l'instance principale redémarre. Ils continuent de répondre aux demandes de lecture lors des redémarrages de l'instance principale, garantissant ainsi une meilleure disponibilité.

Haute disponibilité grâce à des clusters mondiaux

Pour garantir une haute disponibilité sur plusieurs Régions AWS sites, vous pouvez configurer des clusters mondiaux Amazon DocumentDB. 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 dans toutes les régions. Amazon DocumentDB gère automatiquement la réplication de toutes les données et les 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 contenir jusqu'à 15 instances de réplication en plus de la principale.

Lorsque vous créez un cluster à l'aide de Console de gestion AWS, 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. Pour ajouter d'autres répliques à un cluster Amazon DocumentDB, consultez. Ajouter une instance Amazon DocumentDB à un cluster

Lorsque vous utilisez le AWS CLI pour créer votre cluster, vous devez créer explicitement votre instance principale et votre instance de réplication. Pour plus d'informations, consultez la section AWS CLI« Utilisation du » dans les rubriques suivantes :

• Création d'un cluster Amazon DocumentDB

• Ajouter une instance Amazon DocumentDB à un cluster

Décalage de réplication

Le délai de réplication est généralement inférieur ou égal à 50 ms. Les raisons les plus courantes de l'augmentation du décalage des répliques sont les suivantes :

• Un taux d'écriture élevé sur le primaire qui entraîne un retard des répliques de lecture par rapport au principal.

• Conflit sur les répliques de 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 d'écriture entrante.

• Très grand nombre de requêtes simultanées sur les répliques lues.

Pour minimiser les délais de réplication, essayez les techniques de dépannage suivantes :

• Si votre taux d'écriture ou votre taux d'utilisation du processeur est élevé, augmentez la taille des instances de votre cluster.

• Si vos répliques lues font l'objet de longues requêtes et que des mises à jour très fréquentes sont apportées aux documents interrogés, pensez à modifier vos requêtes de longue durée ou à les exécuter sur la primary/write réplique pour éviter tout conflit sur les répliques lues.

• S'il existe un très grand nombre de requêtes simultanées ou si l'utilisation du processeur est élevée 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.

• Étant donné que le retard de réplication est dû à un débit d'écriture élevé et à des requêtes de longue durée, résolvez le problème du retard de réplication en utilisant la DBClusterReplicaLagMaximum CloudWatch métrique en combinaison avec l'enregistreur de requêtes lent et WriteThroughput les métriques/. WriteIOPS

Assurez-vous que toutes vos répliques sont du même type d'instance afin qu'un basculement de cluster n'entraîne pas de dégradation des performances.

Si vous choisissez entre la mise à l'échelle et la mise à l'échelle (par exemple, six instances plus petites contre trois instances plus grandes), nous vous recommandons généralement d'essayer d'abord d'augmenter la taille (instances plus grandes) avant de procéder à la mise à l'échelle, 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 fixer son seuil à une valeur qui, selon vous, correspond à la limite supérieure du retard (ou « obsolète ») que peuvent prendre vos données sur les instances de réplication avant qu'elles ne commencent à affecter les fonctionnalités de votre application. En général, il est conseillé de dépasser le seuil de latence de réplication pour plusieurs points de données avant d'émettre une alarme, en raison de charges de travail transitoires.

Note

Définissez une autre alarme pour les retards de réplication supérieurs à 10 secondes. Si vous dépassez ce seuil pour plusieurs points de données, augmentez la taille de vos instances ou réduisez votre débit d'écriture sur l'instance principale.