Utilisation d’Amazon Aurora Global Database - Amazon Aurora
Présentation d’Aurora Global DatabaseAvantages d’Amazon Aurora Global DatabaseDisponibilité des régions et des versionsLimites d’Aurora Global Database

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.

Utilisation d’Amazon Aurora Global Database

Avec la fonctionnalité Amazon Aurora Global Database, vous pouvez configurer plusieurs clusters de bases de données Aurora répartis sur plusieurs Régions AWS. Aurora synchronise automatiquement toutes les modifications apportées dans le cluster de bases de données principal avec un ou plusieurs clusters secondaires. Une base de données globale Aurora a un cluster de bases de données principal dans une région et jusqu’à 10 clusters de bases de données secondaires dans différentes régions. Cette configuration multi-régions assure une reprise rapide dans les rares cas où une panne pourrait affecter une Région AWS entière. Le fait de disposer d’une copie complète de toutes vos données dans plusieurs zones géographiques permet également d’effectuer des opérations de lecture à faible latence pour les applications qui se connectent à partir de lieux très éloignés dans le monde entier.

Rubriques

Présentation d’Amazon Aurora Global Database

Avec la fonctionnalité Amazon Aurora Global Database, vous pouvez exécuter vos applications distribuées à l’échelle mondiale à l’aide d’une base de données Aurora unique couvrant plusieurs Régions AWS.

Une base de données globale Aurora se compose d’une Région AWS principale dans laquelle vos données sont écrites, et de jusqu’à 10 Régions AWS secondaires en lecture seule. Vous devez émettre les opérations d’écriture directement vers le cluster de bases de données principal de l’Région AWS principale. La méthode la plus pratique consiste à se connecter au point de terminaison d’enregistreur Aurora Global Database, qui pointe toujours vers le cluster de bases de données principal, même après une opération de bascule ou de basculement vers une autre Région AWS. Après une opération d’écriture, Aurora réplique les données vers les Régions AWS secondaires en utilisant une infrastructure dédiée, avec une latence généralement inférieure à une seconde.

Le diagramme suivant illustre un exemple de base de données globale Aurora couvrant deux Régions AWS.

Une base de données globale Aurora a un seul cluster principal et au moins un cluster de bases de données Aurora secondaire.

Vous pouvez augmenter verticalement chaque cluster secondaire de manière indépendante. Pour ce faire, ajoutez-y une ou plusieurs instances de lecteur Aurora afin de répondre aux besoins des charges de travail en lecture seule. Pour une mise à l’échelle encore plus granulaire et flexible, vous pouvez utiliser Aurora Serverless v2 pour les instances de lecteur.

Seul le cluster principal exécute les opérations d’écriture. Les clients qui effectuent des opérations d’écriture se connectent au point de terminaison d’enregistreur Aurora Global Database, qui pointe toujours vers l’instance de base de données d’enregistreur du cluster principal. Comme indiqué dans le diagramme, Aurora utilise le volume de stockage du cluster et non le moteur de base de données pour assurer une réplication rapide à moindre coût. Pour en savoir plus, consultez Présentation du stockage Amazon Aurora.

Aurora Global Database est conçu pour les applications ayant une empreinte mondiale. Les clusters de bases de données secondaires en lecture seule dans plusieurs Régions AWS prennent en charge les opérations de lecture au plus près des utilisateurs de l’application. Grâce à la fonctionnalité de transfert d’écriture, vous pouvez aussi configurer une base de données globale afin que les clusters secondaires envoient les demandes au cluster principal. Pour plus d’informations, consultez Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora.

Aurora Global Database prend en charge deux opérations différentes pour modifier la région de votre cluster de bases de données principal, selon le scénario qui s’applique : bascule Aurora Global Database et basculement Aurora Global Database.

  • Pour les procédures opérationnelles planifiées telles que la rotation régionale, utilisez le mécanisme de bascule (qui s’appelait auparavant « basculement planifié géré »). Avec cette fonctionnalité, vous pouvez relocaliser le cluster principal d’une base de données Aurora Global Database saine vers l’une de ses régions secondaires sans perte de données. Pour en savoir plus, consultez Réalisation de bascules pour les bases de données Amazon Aurora Global Database.

  • Pour récupérer votre base de données Aurora Global Database après une panne dans la région principale, utilisez le mécanisme de basculement. Cette fonctionnalité vous permet de basculer votre cluster de bases de données principal vers une autre région (basculement entre régions). Pour en savoir plus, consultez Réalisation de basculements gérés pour les bases de données globales Aurora.

Avantages d’Amazon Aurora Global Database

Amazon Aurora Global Database offre les avantages suivants :

  • Lecture globale avec latence locale : si vous avez des bureaux dans le monde entier, vous pouvez utiliser Aurora Global Database pour mettre à jour vos principales sources d’information dans la Région AWS principale. Les bureaux de vos autres régions peuvent accéder aux informations dans leur propre région, avec une latence locale.

  • Clusters de bases de données Aurora secondaires évolutifs : vous pouvez mettre à l’échelle vos clusters secondaires en ajoutant d’autres instances en lecture seule à une Région AWS secondaire. Le cluster secondaire est en lecture seule, de sorte qu’il peut prendre en charge jusqu’à 16 instances de base de données en lecture seule, au lieu de 15 habituellement par cluster Aurora.

  • Réplication rapide du cluster de bases de données Aurora principal vers les clusters secondaires : la réplication effectuée par Aurora Global Database a peu d’impact sur les performances du cluster de bases de données principal. Les ressources des instances de base de données sont entièrement dévouées aux charges de travail d’application en lecture et en écriture.

  • Récupération suite aux pannes à l’échelle de la région : les clusters secondaires vous permettent de rendre une base de données Aurora Global Database disponible dans une nouvelle Région AWS principale plus rapidement (RTO moins élevé) et avec moins de perte de données (RPO moins élevé) que les solutions de réplication traditionnelles.

Disponibilité des régions et des versions

La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données Aurora, et selon les Régions AWS. Pour en savoir plus sur les versions et les régions disponibles pour Aurora Global Database, consultez Régions et moteurs de base de données pris en charge pour les bases de données globales Aurora.

Limites d’Amazon Aurora Global Database

Les limites suivantes s’appliquent actuellement à Aurora Global Database :

  • Aurora Global Database est disponible dans certaines Régions AWS et pour certaines versions spécifiques d’Aurora MySQL et Aurora PostgreSQL. Pour plus d’informations, consultez Régions et moteurs de base de données pris en charge pour les bases de données globales Aurora.

  • Aurora Global Database présente des exigences de configuration spécifiques pour les classes d’instance de base de données Aurora prises en charge, le nombre maximal de Régions AWS, etc. Pour plus d’informations, consultez Configuration requise pour une base de données Amazon Aurora globale.

  • Pour Aurora MySQL avec la compatibilité MySQL 5.7, les bascules de bases de données globales Aurora nécessitent la version 2.09.1 ou une version mineure supérieure.

  • Vous ne pouvez effectuer une bascule ou un basculement géré entre régions avec Aurora Global Database que si les clusters de bases de données principal et secondaires possèdent les mêmes versions de moteur majeures et mineures. Selon le moteur et les versions du moteur, les niveaux de correctifs doivent parfois être identiques ou peuvent être différents. Pour obtenir la liste des moteurs et des versions de moteur qui autorisent ces opérations entre les clusters principaux et secondaires avec différents niveaux de correctif, consultez Compatibilité des niveaux de correctif pour les bascules ou basculements gérés entre régions. Si les versions de votre moteur nécessitent des niveaux de correctifs identiques, vous pouvez effectuer le basculement manuellement en suivant les étapes décrites dans Réalisation de basculements manuels pour les bases de données globales Aurora.

  • Aurora Global Database ne prend actuellement pas en charge les fonctionnalités Aurora suivantes :

    • Aurora Serverless v1

    • Retour sur trace dans Aurora

  • Pour connaître les limites de l’utilisation de la fonctionnalité de proxy RDS avec Aurora Global Database, consultez Limites pour le proxy RDS avec les bases de données globales.

  • La mise à niveau automatique des versions mineures ne s’applique pas aux clusters Aurora MySQL et Aurora PostgreSQL qui font partie d’une base de données globale. Notez que vous pouvez spécifier ce paramètre pour une instance de base de données faisant partie d’un cluster de bases de données globale, mais ce paramètre est sans effet.

  • Aurora Global Database ne prend actuellement pas en charge Aurora Auto Scaling pour les clusters de bases de données secondaires.

  • Pour utiliser Database Activity Streams (DAS) sur Aurora Global Database avec Aurora MySQL 5.7, utilisez un moteur version 2.08 ou supérieure. Pour en savoir plus sur DAS, consultez Surveillance d’Amazon Aurora à l’aide des flux d’activité de base de données.

  • Les limites suivantes s’appliquent actuellement à la mise à niveau d’Aurora Global Database :

    • Vous ne pouvez pas appliquer un groupe de paramètres personnalisés au cluster de bases de données globale pendant que vous effectuez une mise à niveau majeure de la version de cette base de données globale Aurora. Vous créez vos groupes de paramètres personnalisés dans chaque région du cluster global et vous les appliquez manuellement aux clusters régionaux après la mise à niveau.

    • Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez pas effectuer une mise à niveau sur place d’Aurora MySQL version 2 vers la version 3 si le paramètre lower_case_table_names est activé. Pour plus d’informations sur les méthodes que vous pouvez utiliser, consultez Mises à niveau de version majeure..

    • Avec Aurora Global Database, vous ne pouvez pas effectuer de mise à niveau de version majeure du moteur de base de données Aurora PostgreSQL si la fonctionnalité d’objectif de point de reprise (RPO) est activée. Pour en savoir plus sur la fonction RPO, consultez Gestion des RPO pour les bases de données globales basées sur Aurora PostgreSQL–.

    • Avec Aurora Global Database, vous ne pouvez pas effectuer une mise à niveau de version mineure de la version 3.01 ou 3.02 d’Aurora MySQL vers la version 3.03 ou supérieure en utilisant le processus standard. Pour plus de détails sur le processus à utiliser, consultez Mise à niveau d’Aurora MySQL par modification de la version du moteur.

    Pour plus d’informations sur la mise à niveau d’Aurora Global Database, consultez Création d’une Amazon Aurora Global Database.

  • Vous ne pouvez pas arrêter ou démarrer les clusters de bases de données Aurora dans votre base de données globale individuellement. Pour en savoir plus, consultez Arrêt et démarrage d’un cluster de bases de données Amazon Aurora.

  • Les instances de base de données de lecteur Aurora attachées au cluster de bases de données Aurora secondaire peuvent redémarrer dans certaines circonstances. Si l’instance de base de données d’enregistreur de la Région AWS principale redémarre ou bascule, les instances de base de données de lecteur des régions secondaires redémarrent également. Le cluster secondaire est alors indisponible tant que toutes les instances de base de données de lecteur ne sont pas resynchronisées avec l’instance d’enregistreur du cluster de bases de données principal. Le comportement du cluster principal lors du redémarrage ou d’un basculement est le même que celui d’un cluster de bases de données unique non global. Pour plus d’informations, consultez Réplication avec Amazon Aurora.

    Assurez-vous de bien comprendre les impacts qu’elles auront sur votre base de données globale avant d’apporter des modifications à votre cluster de bases de données principal. Pour en savoir plus, consultez Reprise d’une base de données Amazon Aurora globale à partir d’une panne non planifiée.

  • Aurora Global Database ne prend actuellement pas en charge le statut inaccessible-encryption-credentials-recoverable quand Amazon Aurora perd l’accès à la clé AWS KMS pour le cluster de bases de données. Dans ce cas, le cluster de bases de données chiffré passe directement à l’état inaccessible-encryption-credentials terminal. Pour plus d’informations sur les états, consultez Affichage du statut du cluster de bases de données.

  • Secrets Manager ne prend pas en charge Aurora Global Database. Lorsque vous ajoutez une région à une base de données globale, vous devez d’abord désactiver l’intégration Secrets Manager pour l’instance de base de données.

  • Les clusters de bases de données basés sur Aurora PostgreSQL qui utilisent Aurora Global Database présentent les limitations suivantes :

    • La gestion des caches de clusters n’est pas prise en charge pour les clusters de bases de données Aurora PostgreSQL qui font partie des bases de données globales Aurora.

    • Si le cluster de bases de données principal de votre base de données globale est basé sur un réplica d’une instance Amazon RDS PostgreSQL, vous ne pouvez pas créer de cluster secondaire. N’essayez pas de créer un secondaire à partir de ce cluster à l’aide de la AWS Management Console, de l’AWS CLI, ou de l’opération d’API CreateDBCluster. Vos tentatives expireront et le cluster secondaire ne sera pas créé.

Nous vous recommandons de créer les clusters de bases de données secondaires pour vos bases de données globales à l’aide de la version du moteur de base de données Aurora utilisée pour le cluster principal. Pour plus d’informations, consultez Création d’une base de données Amazon Aurora globale.