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 vers ou depuis un cluster Aurora, vous pouvez choisir entre des fonctionnalités intégrées telles que les bases de données globales Aurora ou les mécanismes de réplication traditionnels pour les moteurs de SQL base de données My SQL ou Postgre. 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 Postgre SQL suivantes :
Versions 14.6 et antérieures
Versions 13.9 et antérieures
Versions 12.13 et antérieures
Toutes les versions d'Aurora Postgre SQL 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 My SQL 2.10 et versions ultérieures, Aurora redémarre uniquement l'instance de base de données du rédacteur 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 My SQL
Outre les répliques Aurora, vous disposez des options suivantes pour la réplication avec Aurora My SQL :
-
Clusters Aurora My SQL DB 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 Aurora My SQL DB dans une autre AWS région à l'aide de la réplication My SQL binary log (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 Aurora My SQL DB dans la même région, en utilisant la réplication My SQL binary log (binlog).
-
Une instance RDS for My SQL DB comme source de données et un cluster Aurora My SQL DB, en créant une réplique en lecture Aurora d'une instance RDS for My SQL DB. Généralement, vous utilisez cette approche pour la migration vers Aurora MySQL, plutôt que pour une réplication continue.
Pour plus d'informations sur la réplication avec Aurora MySQL, consultezRéplication avec Amazon Aurora My SQL.
Réplication avec Aurora Postgre SQL
Outre les répliques Aurora, vous disposez des options suivantes pour la réplication avec Aurora SQL Postgre :
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 Postgre SQL ne prend pas en charge les répliques Aurora interrégionales. Cependant, vous pouvez utiliser la base de données globale Aurora pour adapter les capacités de lecture de votre SQL cluster de base de données Aurora Postgre à plusieurs AWS 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 SQL base de données Aurora Postgre dans la même région, en utilisant la fonction de réplication logique SQL de Postgre.
Une SQL instance RDS de base de données Postgre comme source de données et un cluster de SQL base de données Aurora Postgre, en créant une réplique en lecture Aurora d'une instance de base de données RDS pour PostgreSQL. Généralement, vous utilisez cette approche pour la migration vers Aurora PostgreSQL, plutôt que pour une réplication continue.
Pour plus d'informations sur la réplication avec Aurora PostgreSQL, consultezRéplication avec Amazon Aurora Postgre SQL.
