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 base de données principale Région AWS dans laquelle vos données sont écrites et d'un maximum de 10 bases secondaires en lecture seule. Régions AWS 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 chaque opération d'écriture, 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.

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 base de données secondaires en lecture seule répartis en plusieurs Régions AWS permettent d'optimiser 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 :

  • La base de données globale Aurora est disponible dans certaines versions Régions AWS et pour des versions spécifiques d'Aurora MySQL et d'Aurora PostgreSQL. Pour de plus amples informations, veuillez consulter 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 Région AWS de données d'écriture du serveur principal est redémarrée ou basculée, les instances de base de données de lecture 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, veuillez consulter la section Reprise d’une base de données Amazon Aurora globale à partir d’une panne non planifiée.

  • La base de données globale Aurora ne prend 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 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' AWS Management Console aide 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 à 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.