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é : AZ1AZ2, 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

• Basculement d'Amazon DocumentDB

  • Contrôle de la cible de basculement

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

• Ajouter une instance Amazon DocumentDB à un cluster

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 d'CPUutilisation 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'CPUutilisation é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.

• 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 DBClusterReplicaLagMaximum 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.