Utilisation de bases de données globales Amazon Aurora

Les bases de données mondiales Amazon Aurora s'étendent sur plusieurs bases de données Régions AWS, ce qui permet des lectures globales à faible latence et une restauration rapide après les rares pannes susceptibles d'affecter l'ensemble d'une base de données Région AWS. Une base de données globale Aurora a un cluster de base de données principal dans une région et jusqu'à cinq clusters de base de données secondaires dans différentes régions.

Rubriques

• Présentation des bases de données globales Amazon Aurora
• Avantages des bases de données globales Amazon Aurora
• Disponibilité des régions et des versions
• Limites des bases de données globales Amazon Aurora
• Mise en route avec les bases de données Amazon Aurora globales
• Gestion d'une base de données Amazon Aurora globale
• Connexion à une base de données Amazon Aurora globale
• Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora
• Utilisation de la commutation ou du basculement dans une base de données globale Amazon Aurora
• Surveillance d'une base de données globale Amazon Aurora
• Utilisation des bases de données globales Amazon Aurora avec d'autres services AWS
• Création d'une Amazon Aurora Global Database

Présentation des bases de données globales Amazon Aurora

En utilisant une Amazon Aurora Global Database, vous pouvez exécuter vos applications distribuées globalement à 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 base de données principale Région AWS dans laquelle vos données sont écrites et d'un maximum de cinq bases secondaires en lecture seule. Régions AWS Vous émettez les opérations d'écriture directement vers le cluster de base de données principal de l' Région AWS principale. Aurora réplique les données vers le secondaire à l' Régions AWS aide d'une infrastructure dédiée, avec une latence généralement inférieure à une seconde.

Dans le schéma suivant, vous pouvez trouver un exemple de base de données globale Aurora qui s'étend sur deux Régions AWS.

Vous pouvez ajuster à la hausse la capacité du cluster secondaire de manière indépendante. Pour ce faire, ajoutez-y un ou plusieurs réplicas Aurora (instances de base de données Aurora en lecture seule) afin de gérer les charges de travail en lecture seule.

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 du cluster de base de données du cluster principal. Comme indiqué dans le diagramme, la base de données globale Aurora utilise le volume de stockage de cluster et non le moteur de base de données pour la réplication. Pour en savoir plus, consultez Présentation du stockage Amazon Aurora.

Les bases de données globales Aurora sont conçues pour les applications ayant une empreinte mondiale. Les clusters de bases de données secondaires en lecture seule (Régions AWS) vous permettent de prendre 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 Aurora afin que les clusters secondaires envoient des données au cluster principal. Pour de plus amples informations, veuillez consulter Utilisation du transfert d'écriture dans une base de données globale Amazon Aurora.

Une base de données globale Aurora prend en charge deux opérations différentes pour modifier la région de votre cluster de base de données principal, selon le scénario : commutation globale de la base de données et basculement global de la base de données.

• Pour les procédures opérationnelles planifiées telles que la rotation régionale, utilisez la commutation globale de base de données (précédemment appelée « basculement planifié géré »). Avec cette fonctionnalité, vous pouvez relocaliser le cluster principal d'une base de données globale Aurora saine vers l'une de ses Régions secondaires sans perte de données. Pour en savoir plus, veuillez consulter la section Réalisation de commutations pour les bases de données globales Amazon Aurora.

• Pour récupérer votre base de données globale Aurora après une panne dans la région principale, utilisez le basculement global de la base de données. Avec cette fonctionnalité, vous basculez votre cluster de base de données principal vers une autre région (basculement entre régions). Pour en savoir plus, consultez la section Réalisation de basculements gérés pour les bases de données globales Aurora.

Avantages des bases de données globales Amazon Aurora

En utilisant des bases de données globales Aurora, vous pouvez bénéficier des avantages suivants :

• Lecture globale avec latence locale : si vous avez des bureaux dans le monde entier, vous pouvez utiliser une base de données globale Aurora pour mettre à jour vos principales sources d'information dans l' 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 base de données Aurora secondaires évolutifs : vous pouvez mettre à l'échelle vos clusters secondaires en ajoutant d'autres instances en lecture seule (réplicas Aurora) à une Région AWS secondaire. Le cluster secondaire est en lecture seule, de sorte qu'il peut prendre en charge jusqu'à 16 instances de réplica Aurora en lecture seule, plutôt que la limite habituelle de 15 par cluster Aurora.

• Réplication rapide des clusters de base de données Aurora principaux vers les clusters secondaires – La réplication effectuée par une base de données globale Aurora a peu d'impact sur les performances du cluster de base 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 globale Aurora 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 la disponibilité des régions avec Aurora et les bases de données globales, consultez Bases de données globales Aurora.

Limites des bases de données globales Amazon Aurora

Les limites suivantes s'appliquent actuellement aux bases de données globales Aurora :

• Les bases de données globales Aurora sont disponibles uniquement dans certaines Régions AWS versions d'Aurora MySQL et Aurora PostgreSQL et pour des versions spécifiques. Pour de plus amples informations, veuillez consulter Bases de données globales Aurora.

• Les bases de données globales Aurora présentent des exigences de configuration spécifiques pour les classes d'instances de base de données Aurora prises en charge, le nombre maximal de Régions AWS, etc. Pour de plus amples informations, veuillez consulter Configuration requise pour une base de données Amazon Aurora globale.

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

• Vous pouvez effectuer des commutations ou des basculements interrégionaux gérés sur une base de données globale Aurora uniquement si les clusters de base de données principal et secondaire possèdent les mêmes versions de moteur majeures, mineures et de niveau correctif. Cependant, les niveaux de correctif peuvent être différents si les versions mineures du moteur sont les suivantes.

  Moteur de base de données	Versions de moteur mineures
  Aurora PostgreSQL	Version 14.5 ou version mineure ultérieure Version 13.8 ou version mineure ultérieure Version 12.12 ou version mineure ultérieure Version 11.17 ou version mineure ultérieure

  Pour de plus amples informations, veuillez consulter Compatibilité des niveaux de correctif pour les commutations ou basculements entre régions gérés.

• Les bases de données globales Aurora ne prennent 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 les bases de données globales, 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 Aurora. Notez que vous pouvez spécifier ce paramètre pour une instance de base de données faisant partie d'un cluster de base de données globale, mais ce paramètre est sans effet.

• Les bases de données globales Aurora ne prennent actuellement pas en charge Aurora Auto Scaling pour les clusters de base de données secondaire.

• Pour utiliser les flux d'activité des bases de données sur les bases de données globales Aurora exécutant Aurora MySQL 5.7, la version du moteur doit être 2.08 ou supérieure. Pour plus d'informations sur les flux d'activité de base de données, veuillez consulter Surveillance d'Amazon Aurora à l'aide des flux d'activité de base de données.

• Les limitations suivantes s'appliquent actuellement à la mise à niveau des bases de données globales Aurora :

  • Vous ne pouvez pas appliquer un groupe de paramètres personnalisés au cluster de base 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 une base de données globale Aurora basée sur Aurora PostgreSQL, vous ne pouvez pas effectuer de mise à niveau majeure du moteur de base de données Aurora si la fonction Objectif de point de reprise (RPO) est activée. Pour en savoir plus sur la fonction RPO, veuillez consulter Gestion des RPO pour les bases de données globales basées sur Aurora PostgreSQL–.

  • Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez pas effectuer la mise à niveau d'une version mineure de la version 3.01 ou 3.02 vers la version 3.03 ou une version ultérieure en utilisant le processus standard. Pour plus d'informations sur ce processus, consultez Mise à niveau d'Aurora MySQL par modification de la version du moteur.

  Pour plus d'informations sur la mise à niveau d'une base de données globale Aurora, veuillez consulter 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 Aurora individuellement. Pour en savoir plus, consultez la section Arrêt et démarrage d'un cluster de bases de données Amazon Aurora.

• Les réplicas Aurora attachés au cluster de base de données Aurora secondaire peuvent redémarrer dans certaines circonstances. Si l'instance de base Région AWS de données Writer du serveur principal redémarre ou bascule, les répliques Aurora des régions secondaires redémarrent également. Dans ces conditions, le cluster secondaire n'est pas disponible tant que tous les réplicas ne sont pas de nouveau synchronisés avec l'instance de scripteur du cluster de base de données principal. Le comportement du cluster principal lors du redémarrage ou du basculement est le même que celui d'un cluster de base de données unique et non global. Pour de plus amples informations, veuillez consulter Réplication avec Amazon Aurora.

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

• Les bases de données globales Aurora ne prennent actuellement pas en charge le inaccessible-encryption-credentials-recoverable statut lorsqu'Amazon Aurora perd l'accès à la AWS KMS clé du cluster de bases de données. Dans ce cas, le cluster de base 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 base de données.

• Les clusters de bases de données basés sur Aurora PostgreSQL exécutés dans une base de données globale Aurora présentent les limitations suivantes :

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

  • Si le cluster de base de données principal de votre base de données globale Aurora 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' AWS Management Consoleaide de l'opération AWS CLI, de ou de l'CreateDBClusterAPI. 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 Aurora à l'aide de la version du moteur de base de données Aurora utilisée pour le principal. Pour de plus amples informations, veuillez consulter Création d'une base de données Amazon Aurora globale.