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.
Réplication avec Amazon Aurora
Aurora propose plusieurs options de réplication. Chaque cluster de bases de données Aurora dispose d'une réplication intégrée entre plusieurs instances dans le même cluster. Vous pouvez également configurer la réplication avec votre cluster Aurora en tant que source ou cible. Lorsque vous répliquez des données dans ou hors d'un cluster Aurora, vous pouvez choisir entre des fonctionnalités intégrées telles que les bases de données Aurora globales ou les mécanismes de réplication traditionnels pour les moteurs de base de données MySQL ou PostgreSQL. Vous pouvez déterminer les options appropriées en recherchant un équilibre entre haute disponibilité, commodité et performances selon vos besoins. Les sections suivantes expliquent comment et quand choisir chaque technique.
Réplicas Aurora
Lorsque vous créez une deuxième, troisième, etc. instances de base de données dans un cluster de bases de données Aurora provisionné, Aurora configure automatiquement la réplication à partir de l'instance de base de données de scripteur vers toutes les autres instances. Ces autres instances sont en lecture seule et sont appelées des réplicas Aurora. Nous les désignons également comme des instances de lecteur lorsque vous nous parlons de la façon dont vous pouvez combiner des instances de scripteur et de lecteur au sein d'un cluster.
Les réplicas Aurora ont deux objectifs principaux. Vous pouvez émettre des requêtes vers ces derniers pour mettre à l'échelle les opérations de lecture de votre application. Cela se fait généralement en se connectant au point de terminaison du lecteur du cluster. De cette façon, Aurora peut répartir la charge pour les connexions en lecture seule sur l'ensemble des réplicas Aurora disponibles dans le cluster. Les réplicas Aurora aident également à augmenter la disponibilité. Si l'instance de scripteur dans un cluster devient indisponible, Aurora promeut automatiquement l'une des instances de lecteur pour qu'elle prenne sa place en tant que nouveau scripteur.
Un cluster de bases de données Aurora peut contenir jusqu'à 15 réplicas Aurora. Les réplicas Aurora peuvent être répartis entre les zones de disponibilité couvertes par un cluster de bases de données au sein d'une même région AWS .
Les données de votre cluster de bases de données possèdent leurs propres fonctions de haute disponibilité et de fiabilité, indépendantes des instances de base de données du cluster. Si vous n'êtes pas familier avec les fonctionnalités de stockage d'Aurora, reportez-vous à la section Présentation du stockage Amazon Aurora. Le volume de cluster de bases de données est physiquement composé de plusieurs copies des données du cluster de bases de données. Les données du volume de cluster sont représentées comme un seul volume logique à l'instance principale et aux réplicas Aurora du cluster de bases de données.
En conséquence, tous les réplicas Aurora renvoient les mêmes données pour les résultats des requêtes avec un retard de réplica minimal. Ce retard est généralement bien inférieur à 100 ms après que l'instance principale a écrit une mise à jour. Le retard de réplica varie en fonction de la fréquence de modification de la base de données. Autrement dit, pendant les périodes où une importante quantité d'opérations d'écriture se produit pour la base de données, il se peut que vous constatiez un retard accru du réplica.
Note
Aurora Replica redémarre lorsqu'elle perd la communication avec l'instance de base de données du rédacteur pendant plus de 60 secondes dans les versions d'Aurora PostgreSQL suivantes :
Versions 14.6 et antérieures
Versions 13.9 et antérieures
Versions 12.13 et antérieures
Toutes les versions d'Aurora PostgreSQL 11
Les réplicas Aurora fonctionnement parfaitement pour le dimensionnement en lecture, car ils sont intégralement dédiés aux opérations de lecture de votre volume de cluster. Les opérations d'écriture sont gérées par l'instance principale. Sachant que le volume de cluster est partagé entre toutes les instances de base de données de votre cluster de bases de données, la réplication d'une copie des données de chaque réplica Aurora nécessite peu d'efforts.
Pour accroître la disponibilité, vous pouvez utiliser les réplicas Aurora comme cibles de basculement. En d'autres termes, si l'instance principale est défaillante, un réplica Aurora peut être promu instance principale. Il y a une brève interruption, pendant laquelle les demandes de lecture et d'écriture adressées à l'instance principale échouent en renvoyant une exception.
La promotion d'un réplica Aurora par basculement est beaucoup plus rapide que la recréation de l'instance principale. Si votre cluster de base de données Aurora ne comporte pas de réplicas Aurora, il ne sera pas disponible pendant que votre instance de base de données récupérera de la défaillance.
Lors du basculement, certains réplicas Aurora peuvent être redémarrés, en fonction de la version du moteur de base de données. Par exemple, dans Aurora MySQL 2.10 et versions ultérieures, Aurora redémarre uniquement l'instance de base de données d'enregistreur et la cible de basculement lors d'un basculement. Pour plus d'informations sur le comportement de redémarrage des différentes versions du moteur de base de données Aurora, consultez Redémarrage d'un cluster de bases de données Amazon Aurora ou d'une instance de base de données Amazon Aurora. Pour obtenir des informations sur ce qu'il advient des caches de pages lors du redémarrage ou du basculement, consultez Cache de page durable.
Pour les scénarios de haute disponibilité, il est recommandé de créer un ou plusieurs réplicas Aurora. Ceux-ci doivent avoir la même classe d'instance de base de données que l'instance principale, et se trouver dans des zones de disponibilité différentes de votre cluster de bases de données Aurora. Pour plus d'informations sur les réplicas Aurora comme cibles de basculement, veuillez consulter Tolérance aux pannes pour un cluster de base de données Aurora.
Vous ne pouvez pas créer de réplica Aurora chiffré pour un cluster de base de données Aurora non chiffré. Vous ne pouvez pas créer de réplica Aurora non chiffré pour un cluster de base de données Aurora chiffré.
Astuce
Vous pouvez utiliser des réplicas Aurora au sein d'un cluster Aurora comme seule forme de réplication pour maintenir vos données hautement disponibles. Vous pouvez également combiner la réplication Aurora intégrée avec les autres types de réplication. Cela peut vous aider à assurer un niveau de disponibilité et de distribution géographique de vos données encore supérieur
Pour plus de détails sur la création d'un réplica Aurora, consultez Ajout de réplicas Aurora à un cluster de bases de données.
Réplication avec Aurora MySQL
En plus des réplicas Aurora, Aurora MySQL propose les options de réplication suivantes :
-
Clusters de bases de données Aurora MySQL dans différentes AWS régions.
-
Vous pouvez répliquer des données sur plusieurs régions à l'aide d'une base de données Aurora globale. Pour plus d'informations, consultez Haute disponibilité dans les régions AWS avec des bases de données Aurora globales.
-
Vous pouvez créer une réplique en lecture Aurora d'un cluster de bases de données Aurora MySQL dans une autre AWS région, en utilisant la réplication du journal binaire MySQL (binlog). Il est possible de créer de cette façon jusqu'à cinq réplicas en lecture par cluster, chacun dans une Région différente.
-
-
Deux clusters de bases de données Aurora MySQL dans la même région , en utilisant la réplication du journal binaire (binlog) MySQL.
-
Une instance source de données de base de données RDS for MySQL et un cluster de base de données Aurora MySQL, en créant un réplica en lecture Aurora d'une instance de base de données RDS for MySQL. Cette approche est généralement utilisée pour une migration vers Aurora MySQL plutôt que pour une réplication continue.
Pour plus d'informations sur la réplication avec Aurora MySQL, consultez Réplication avec Amazon Aurora MySQL.
Réplication avec Aurora PostgreSQL
En plus des réplicas Aurora, Aurora PostgreSQL propose les options de réplication suivantes :
Un cluster de bases de données Aurora principal dans une région et jusqu'à cinq clusters secondaires en lecture seule dans différentes régions en utilisant une base de données Aurora globale. Aurora PostgreSQL ne prend pas en charge les réplicas Aurora entre Régions. Cependant, vous pouvez utiliser la base de données globale Aurora pour adapter les capacités de lecture de votre cluster de bases de données Aurora PostgreSQL à AWS plusieurs régions et pour atteindre les objectifs de disponibilité. Pour de plus amples informations, veuillez consulter Utilisation de bases de données globales Amazon Aurora.
Deux clusters de bases de données Aurora PostgreSQL dans la même Région, à l'aide de la fonctionnalité de réplication logique de PostgreSQL.
Une instance de base de données RDS for PostgreSQL en tant que source de données et un cluster de base de données Aurora PostgreSQL, en créant un réplica en lecture Aurora d'une instance de base de données RDS PostgreSQL. Cette approche est généralement utilisée pour une migration vers Aurora PostgreSQL plutôt que pour une réplication continue.
Pour plus d'informations sur la réplication avec Aurora PostgreSQL, consultez Réplication avec Amazon Aurora PostgreSQL.
