View a markdown version of this page

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 conçus pour être 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.

Si l'instance principale d'un cluster tombe en panne, Amazon DocumentDB effectue automatiquement un basculement vers une nouvelle instance principale de deux manières :

  • En faisant la promotion d'un réplica Amazon DocumentDB existant vers la nouvelle instance principale choisie en fonction du paramètre de niveau de promotion de chaque réplica, puis en créant une instance de remplacement pour l'ancienne instance principale. Le basculement vers l'instance de réplication prend généralement moins de 30 secondes. Les opérations de lecture et d'écriture peuvent subir de brèves interruptions pendant cette période. Pour améliorer la disponibilité de votre cluster, créez 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 se produit uniquement si vous ne possédez pas d'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 vers l'instance principale lors d'un événement 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 améliorer la disponibilité de votre cluster, créez 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 un échec en attribuant une priorité à chaque réplica. Les priorités s’étendent de la valeur 0 pour la plus haute priorité à la valeur 15 pour la plus basse priorité. Si l'instance principale échoue, 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 entraîne des niveaux de promotion. Si au moins deux réplicas Amazon DocumentDB partagent la même priorité, le réplica dont la taille est la plus grande est promue au rang de réplica principal. Si deux répliques Amazon DocumentDB ou plus partagent la même priorité et la même taille, une réplique arbitraire du 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'un réplica Amazon DocumentDB vers l'instance principale est beaucoup plus rapide que la création d'une nouvelle instance principale.