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

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.

Comprendre la tolérance aux pannes des clusters Amazon DocumentDB

Les clusters Amazon DocumentDB sont par conception tolérants aux pannes. Le volume de chaque cluster couvre plusieurs zones de disponibilité en une seule Région AWS, et chaque zone de disponibilité contient une copie des données de volume du cluster. Cette fonctionnalité signifie que votre cluster peut tolérer une défaillance d'une zone de disponibilité sans perte de données et uniquement une brève interruption de service.

En cas de défaillance de l'instance principale d'un cluster, Amazon DocumentDB effectue automatiquement un basculement vers une nouvelle instance principale de deux manières :

  • En promouvant une réplique Amazon DocumentDB existante vers la nouvelle instance principale choisie en fonction du paramètre de niveau de promotion de chaque réplique, puis en créant une instance de remplacement pour l'ancienne instance principale. Le basculement vers l'instance de réplique prend généralement moins de 30 secondes. Les opérations de lecture et d'écriture peuvent être brièvement interrompues pendant cette période. Pour augmenter la disponibilité de votre cluster, nous vous recommandons de créer au moins une ou plusieurs répliques Amazon DocumentDB dans au moins deux zones de disponibilité différentes.

  • Par la création d'une nouvelle instance principale. Cela ne se produit que si vous ne disposez pas d'une instance de réplication dans votre cluster et cela peut prendre quelques minutes.

Si le cluster possède une ou plusieurs répliques Amazon DocumentDB, une réplique Amazon DocumentDB est promue en instance principale en cas de défaillance. Un événement d'échec se traduit par une brève interruption, pendant laquelle les opérations de lecture et d'écriture échouent avec une exception. Cependant, le service est généralement restauré en moins de 120 secondes, et souvent en moins de 60 secondes. Pour augmenter la disponibilité de votre cluster, nous vous recommandons de créer au moins une ou plusieurs répliques Amazon DocumentDB dans au moins deux zones de disponibilité différentes.

Vous pouvez personnaliser l'ordre dans lequel vos répliques Amazon DocumentDB sont promues vers l'instance principale après une panne en attribuant une priorité à chaque réplique. Les priorités s'étendent de la valeur 0 pour la plus haute priorité à la valeur 15 pour la plus basse priorité. En cas de défaillance de l'instance principale, la réplique Amazon DocumentDB ayant la priorité la plus élevée est promue vers la nouvelle instance principale. Vous pouvez modifier la priorité d'une réplique Amazon DocumentDB à tout moment. La modification de la priorité ne déclenche pas un basculement. Vous pouvez utiliser l'opération modify-db-instance avec le paramètre --promotion-tier. Pour en savoir plus sur la personnalisation de la priorité de basculement d'une instance, consultez Basculement d'Amazon DocumentDB.

Plusieurs répliques Amazon DocumentDB peuvent partager la même priorité, ce qui se traduit par des niveaux de promotion. Si deux répliques Amazon DocumentDB ou plus partagent la même priorité, la réplique la plus grande est promue en tant que réplique principale. Si deux répliques Amazon DocumentDB ou plus partagent la même priorité et la même taille, une réplique arbitraire appartenant au même niveau de promotion est promue.

Si le cluster ne contient aucune réplique Amazon DocumentDB, l'instance principale est recréée lors d'un événement de défaillance. Un événement d'échec se traduit par une interruption, pendant laquelle les opérations de lecture et d'écriture échouent avec une exception. Le service est rétabli quand la nouvelle instance principale est créée, ce qui prend généralement moins de 10 minutes. La promotion d'une réplique Amazon DocumentDB vers l'instance principale est beaucoup plus rapide que la création d'une nouvelle instance principale.