Clusters et instances de base de données Amazon Neptune - Amazon Neptune

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.

Clusters et instances de base de données Amazon Neptune

Un Amazon NeptuneCluster DBgère l'accès à vos données par le biais de requêtes. Un cluster est composé de :

  • Uninstance de base de données primaire..

  • Jusqu'à 15instances de base de données en lecture-réplique..

Toutes les instances d'un cluster partagent les mêmesvolume de stockage géré sous-jacent, conçu dans un souci de fiabilité et de haute disponibilité.

Vous vous connectez aux instances de base de données de votre cluster de bases de données viaTerminaux Neptune.

Instance de base de données principale dans un cluster de base de données Neptune

L'instance de base de données principale coordonne toutes les opérations d'écriture sur le volume de stockage sous-jacent du cluster de bases de Il prend également en charge les opérations de lecture.

Il ne peut y avoir qu'une seule instance de base de données principale dans un cluster de bases de données Neptune. Si l'instance principale devient indisponible, Neptune bascule automatiquement vers l'une des instances de lecture-réplique avec une priorité que vous pouvez spécifier.

Instances de base de données en lecture/réplique dans un cluster de bases de données Neptune

Une fois que vous avez créé l'instance principale d'un cluster de base de données, vous pouvez créer jusqu'à 15 instances de réplica en lecture seule dans votre cluster de base de données pour prendre en charge les requêtes en lecture seule.

Les instances de base de données de réplica en lecture de Neptune fonctionnement parfaitement pour le dimensionnement de la capacité de lecture, car ils sont intégralement dédiés aux opérations de lecture de votre volume de cluster. Toutes les opérations d'écriture sont gérées par l'instance principale. Chaque instance de base de données en lecture-réplique possède son propre point de terminaison.

Comme le volume de stockage du cluster est partagé entre toutes les instances d'un cluster, toutes les instances de lecture-réplique renvoient les mêmes données pour les résultats des requêtes avec un très faible décalage de réplication. Ce retard est généralement bien inférieur à 100 ms après que l'instance principale a écrit une mise à jour, mais il peut être un peu plus élevé lorsque le volume des opérations d'écriture est très élevé.

Le fait de disposer d'une ou de plusieurs instances de réplica en lecture dans différentes zones de disponibilité peut augmenter la disponibilité, car les répliques en lecture servent de cibles de basculement pour l'instance principale. En d'autres termes, si l'instance principale est défaillante, Neptune fait de l'instance de réplica de lecture l'instance principale. Dans ce cas, une brève interruption est à observer pendant le redémarrage de l'instance promue, durant laquelle les demandes de lecture et d'écriture adressées à l'instance principale échouent avec une exception.

En revanche, si votre cluster de bases de données n'inclut aucune instance de réplica en lecture, votre cluster de bases de données reste indisponible lorsque l'instance principale tombe en panne jusqu'à ce qu'elle soit recréée. La recréation de l'instance principale prend beaucoup plus de temps que la promotion d'une réplique en lecture.

Pour garantir une haute disponibilité, nous vous recommandons de créer une ou plusieurs instances de réplica en lecture ayant la même classe d'instance de base de données que l'instance principale et situées dans des zones de disponibilité différentes de celles de l'instance principale. Consultez Tolérance aux pannes pour un cluster DB Neptune.

À l'aide de la console, vous pouvez créer un déploiement multi-AZ en spécifiant simplement l'option Multi-AZ lors de la création d'un cluster DB. Si un cluster de base de données se trouve dans une zone de disponibilité unique, vous pouvez en faire un cluster de base de données multi-AZ en ajoutant une réplique Neptune dans une zone de disponibilité différente.

Note

Vous ne pouvez pas créer d'instance de réplica en lecture cryptée pour un cluster de base de données Neptune non crypté, ni d'instance de réplica en lecture non cryptée pour un cluster de bases de données Neptune crypté.

Pour plus de détails sur la création d'une instance de base de données Neptune en lecture et en réplica, consultezCréation d'un réplica Neptune à l'aide de la console.

Dimensionnement des instances de base de données dans un cluster de bases de données

Dimensionnez les instances de votre cluster de base de données Neptune en fonction de vos besoins en matière de processeur et de mémoire Le nombre de vCPUs sur une instance détermine le nombre de threads de requête qui gèrent les requêtes entrantes. La quantité de mémoire d'une instance détermine la taille du cache tampon, utilisé pour stocker des copies des pages de données extraites du volume de stockage sous-jacent.

Chaque instance de base de données Neptune possède un nombre de threads de requête égal à 2 fois le nombre de vCPUs sur cette instance. Unr4.xlarge, par exemple, avec 2 vCPUs, possède 4 threads de requête et peut donc traiter 4 demandes simultanément. Unr5.4xlarge, avec 16 vCPUs, possède 32 threads de requête et peut donc traiter 32 requêtes simultanément.

Les requêtes supplémentaires qui arrivent alors que tous les threads de requête sont occupés sont placées dans une file d'attente côté serveur et traitées de manière FIFO au fur et à mesure que les threads de requête deviennent disponibles. Cette file d'attente côté serveur peut contenir environ 8 000 demandes en attente. Une fois qu'il est plein, Neptune répond aux demandes supplémentaires parThrottlingException. Vous pouvez suivre le nombre de demandes en attente avec leMainRequestQueuePendingRequests CloudWatch métrique, ou en utilisantPoint de terminaison du statut des requêtes GremlinavecincludeWaitingparamètre.

Du point de vue du client, le temps d'exécution de la requête inclut le temps passé dans la file d'attente, en plus du temps nécessaire à l'exécution effective de la requête.

Une charge d'écriture simultanée soutenue qui utilise tous les threads de requête de l'instance de base de données principale indique idéalement une utilisation du processeur de 90 % ou plus, ce qui indique que tous les threads de requête du serveur sont activement engagés dans des tâches utiles. Cependant, l'utilisation réelle du processeur est souvent légèrement inférieure, même en cas de charge d'écriture simultanée soutenue. En général, les threads de requêtes sont en train d'attendre des opérations I/O du volume de stockage sous-jacent pour se terminer. Neptune utilise des écritures par quorum qui créent six copies de vos données dans trois zones de disponibilité, et quatre de ces six nœuds de stockage doivent accuser réception d'une écriture pour que celle-ci soit considérée comme durable. Lorsqu'un thread de requête attend ce quorum depuis le volume de stockage, il est bloqué, ce qui réduit l'utilisation du processeur.

Si vous avez une charge d'écriture en série où vous effectuez une écriture après l'autre et que vous attendez que la première soit terminée avant de commencer la suivante, vous pouvez vous attendre à ce que l'utilisation du processeur soit encore plus faible. La quantité exacte sera fonction du nombre de vCPUs et de threads de requête (plus il y a de threads de requête, moins il y a de CPU par requête), avec une certaine réduction due à l'attente des E/S.

Surveillance des performances des instances de base de données dans Neptune

Vous pouvez utiliser CloudWatch des mesures dans Neptune pour surveiller les performances de vos instances de base de données et suivre la latence des requêtes telle qu'observée par le client. Consultez A l'aide de CloudWatch pour surveiller les performances des instances de base de données dans Neptune.