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.
Haute disponibilité pour Amazon Aurora
L'architecture Amazon Aurora implique une séparation entre le stockage et le calcul. Aurora comporte des fonctions à haute disponibilité qui s'appliquent aux données de votre cluster de base de données. Les données sont en sécurité, même si certaines ou la totalité des instances de base de données du cluster deviennent indisponibles. D'autres fonctionnalités à haute disponibilité s'appliquent aux instances de base de données. Ces fonctionnalités permettent d'être sûr qu'une ou plusieurs instances de base de données sont prêtes à gérer les demandes adressées à la base de données à partir de votre application.
Rubriques
Haute disponibilité pour les données Aurora
Aurora stocke les copies des données d'un cluster de base de données dans plusieurs zones de disponibilité d'une même Région AWS. Aurora stocke ces copies indépendamment du fait que les instances dans le cluster de base de données recouvrent ou pas plusieurs zones de disponibilité. Pour plus d'informations sur Aurora, consultez Gestion d'un cluster de base de données Amazon Aurora.
Lorsque des données sont écrites dans l'instance de base de données principale, Aurora réplique de façon synchronisée les données entre les zones de disponibilité sur six nœuds de stockage associés au volume de votre cluster. Cela permet de bénéficier de la redondance des données, d'éliminer les figements d'I/O et de minimiser les pics de latence pendant les sauvegardes du système. L'exécution d'une instance de base de données avec la haute disponibilité peut améliorer la disponibilité pendant la maintenance planifiée du système et contribuer à protéger vos bases de données contre toute défaillance ou perturbation d'une zone de disponibilité. Pour plus d'informations sur les zones de disponibilité, consultez Régions et zones de disponibilité.
Haute disponibilité pour les instances de base de données Aurora
Une fois que vous avez créé l'instance principale (d'écriture), vous pouvez créer jusqu'à 15 réplicas Aurora en lecture seule. Les réplicas Aurora sont aussi appelés instances de lecteur.
Pendant day-to-day les opérations, vous pouvez décharger une partie du travail pour les applications nécessitant beaucoup de lecture en utilisant les instances du lecteur pour traiter les requêtes. SELECT Lorsqu'un problème affecte l'instance principale, l'une de ces instances de lecteur prend le relais en tant qu'instance principale. Ce mécanisme est connu sous le nom de basculement. De nombreuses fonctionnalités Aurora s'appliquent au mécanisme de basculement. Par exemple, Aurora détecte les problèmes de base de données et active automatiquement le mécanisme de basculement si nécessaire. Aurora disposent également de fonctions qui réduisent le temps de basculement. Ainsi, le temps pendant lequel la base de données n'est pas disponible pour l'écriture pendant un basculement est réduit.
Aurora est conçu pour restaurer le plus rapidement possible, et le chemin le plus rapide vers la restauration consiste souvent à redémarrer ou à basculer vers la même instance de base de données. Le redémarrage est plus rapide et implique moins de frais que le basculement.
Pour utiliser une chaîne de connexion qui reste identique même lorsqu'un basculement favorise une nouvelle instance principale, vous vous connectez au point de terminaison du cluster. Le point de terminaison du cluster représente toujours l'instance principale actuelle dans le cluster. Pour plus d'informations sur le point de terminaison du cluster, veuillez consulter Connexions aux terminaux Amazon Aurora.
Astuce
Dans chacune d'elles Région AWS, les zones de disponibilité (AZs) représentent des emplacements distincts les uns des autres afin de garantir l'isolation en cas de panne. Nous vous recommandons de répartir l'instance principale et les réplicas et les instances de lecteur de votre cluster de base de données sur plusieurs zones de disponibilité afin d'améliorer la disponibilité de votre cluster de base de données. De cette façon, un problème qui affecte toute une zone de disponibilité ne provoque pas de panne de votre cluster.
Vous pouvez configurer un cluster de base de données multi-AZ en effectuant un choix simple lors de la création du cluster. Vous pouvez utiliser le AWS Management Console, le AWS CLI, ou l'Amazon RDSAPI. Vous pouvez également convertir un cluster de base de données Aurora existant en cluster de base de données multi-AZ en ajoutant une nouvelle instance de base de données de lecteur et en spécifiant une autre zone de disponibilité.
Haute disponibilité dans les régions AWS avec des bases de données Aurora globales
Pour une haute disponibilité sur plusieurs sites Régions AWS, vous pouvez configurer des bases de données globales Aurora. Chaque base de données mondiale Aurora couvre plusieurs bases de données Régions AWS, ce qui permet des lectures globales à faible latence et une reprise après sinistre après des pannes survenant sur un. Région AWS Aurora gère automatiquement la réplication de toutes les données et mises à jour de la région principale Région AWS vers chacune des régions secondaires. Pour de plus amples informations, veuillez consulter Utilisation de bases de données globales Amazon Aurora.
Tolérance aux pannes pour un cluster de base de données Aurora
Un cluster de base de données Aurora est tolérant aux pannes par définition. Le volume de cluster couvre plusieurs zones de disponibilité (AZs) en une seule Région AWS, et chaque zone de disponibilité contient une copie des données du volume de cluster. Cette fonctionnalité signifie que votre cluster de base de données 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 de base de données, Aurora bascule automatiquement vers une nouvelle instance principale de l'une des deux façons suivantes :
-
Par la promotion d'un réplica Aurora existant vers la nouvelle instance principale
-
Par la création d'une nouvelle instance principale
Si le cluster de base de données possède un ou plusieurs réplicas Aurora, un réplica Aurora est promu vers l'instance principale lors d'un événement d'échec. 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 60 secondes, et souvent en moins de 30 secondes. Pour augmenter la disponibilité de votre cluster de base de données, nous vous recommandons de créer au moins un ou plusieurs réplicas Aurora dans deux zones de disponibilité ou plus.
Astuce
Dans Aurora My SQL 2.10 et versions ultérieures, vous pouvez améliorer la disponibilité lors d'un basculement en disposant de plusieurs instances de base de données de lecteur dans un cluster. Dans Aurora My SQL 2.10 et versions ultérieures, Aurora redémarre uniquement l'instance de base de données d'écriture et l'instance de lecteur vers laquelle elle bascule. D'autres instances de lecteur dans le cluster restent disponibles au cours d'un basculement pour continuer le traitement des requêtes par le biais de connexions au point de terminaison de lecteur.
Vous pouvez également améliorer la disponibilité lors d'un basculement en utilisant un RDS proxy avec votre cluster de base de données Aurora. Pour de plus amples informations, veuillez consulter Haute disponibilité avec Amazon RDS Proxy.
Vous pouvez personnaliser l'ordre dans lequel vos réplicas Aurora sont promus vers l'instance principale après un échec, en affectant à chaque réplica une priorité. 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, Amazon RDS fait la promotion de la réplique Aurora avec la plus haute priorité auprès de la nouvelle instance principale. Vous pouvez modifier la priorité d'un réplica Aurora à tout moment. La modification de la priorité ne déclenche pas un basculement.
Plusieurs réplicas Aurora peuvent partager la même priorité, ce qui se traduit par des niveaux de promotion. Si deux répliques Aurora ou plus partagent la même priorité, Amazon RDS fait la promotion de la réplique la plus grande. Si deux répliques Aurora ou plus partagent la même priorité et la même taille, Amazon RDS fait la promotion d'une réplique arbitraire dans le même niveau de promotion.
Si le cluster de base de données ne contient aucun réplica Aurora, l'instance principale est recréée dans la même AZ pendant un événement d'échec. 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 Aurora vers l'instance principale est beaucoup plus rapide que la création d'une nouvelle instance principale.
Supposons que l'instance principale de votre cluster soit indisponible en raison d'une panne affectant une zone de disponibilité entière. Dans ce cas, la façon de mettre en ligne une nouvelle instance principale dépend du fait que votre cluster utilise ou non une configuration Multi-AZ :
-
Si votre Aurora Serverless v2 cluster ou votre provisionnement contient des instances de lecteur dans un autreAZs, Aurora utilise le mécanisme de basculement pour faire de l'une de ces instances de lecteur la nouvelle instance principale.
-
Si votre cluster alloué ou Aurora Serverless v2 contient une instance de base de données unique, ou si l'instance principale et toutes les instances de lecteur se trouvent dans la même zone de disponibilité, veillez à créer manuellement une ou plusieurs instances de base de données dans une autre zone de disponibilité.
-
Si votre cluster utilise Aurora Serverless v1, Aurora crée automatiquement une instance de base de données dans une autre zone de disponibilité. Toutefois, ce processus implique un remplacement d'hôte et prend donc plus de temps qu'un basculement.
Note
Amazon Aurora prend également en charge la réplication avec une instance externe My SQL database ou RDS My SQL DB. Pour de plus amples informations, veuillez consulter Réplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base de données Aurora (réplication de journaux binaires).
Haute disponibilité avec Amazon RDS Proxy
Avec RDS Proxy, vous pouvez créer des applications capables de tolérer de manière transparente les défaillances de base de données sans avoir à écrire un code complexe de gestion des défaillances. Le proxy achemine automatiquement le trafic vers une nouvelle instance de base de données tout en préservant les connexions aux applications. Il contourne également les caches du système de noms de domaine (DNS) afin de réduire les temps de basculement jusqu'à 66 % pour les bases de données multi-AZ Aurora. Pour de plus amples informations, veuillez consulter Utilisation d'Amazon RDS Proxy pour Aurora.
