Réplicas en lecture Amazon RDS

Les réplicas en lecture Amazon RDS offrent des performances et une durabilité accrues pour les instances de base de données (DB) Amazon RDS. Ils facilitent le dimensionnement basé sur Elastic au-delà des contraintes de capacité d'une seule instance de base de données pour les charges de travail de base de données à lecture importante. Vous pouvez créer un ou plusieurs réplicas d'une instance de base de données source donnée et assurer un trafic élevé en lecture d'application depuis plusieurs copies de vos données, augmentant ainsi le débit en lecture agrégé. Il est également possible de promouvoir les réplicas en lecture de manière à ce qu'ils deviennent des instances de base de données autonomes. Les réplicas en lecture sont disponibles dans Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle et SQL Server ainsi que dans Amazon Aurora.

Pour les moteurs de bases de données MySQL, MariaDB PostgreSQL, Oracle et SQL Server, Amazon RDS crée une deuxième instance de base de données en utilisant un instantané de l'instance de base de données source. Il se sert ensuite de la réplication asynchrone native des moteurs pour mettre à jour le réplica en lecture à chaque modification de l'instance de base de données source. Ce réplica en lecture fonctionne comme une instance DB qui autorise uniquement les connexions en lecture seule. Les applications peuvent se connecter à un réplica en lecture de la même façon qu'à toute instance DB. Amazon RDS réplique toutes les bases de données dans l'instance de base de données source.

Amazon Aurora enrichit davantage les avantages des réplicas en lecture en utilisant une couche de stockage virtualisée SSD, spécialement conçue pour les charges de travail des bases de données. Les réplicas Amazon Aurora partagent le même stockage sous-jacent que l'instance source, ce qui permet de réduire les coûts et d'éviter de devoir copier les données vers les nœuds de réplica. Pour en savoir plus sur la réplication avec Amazon Aurora, consultez la documentation en ligne.

Dimensionnement en lecture et reprise après sinistre

Configuration

À l'aide de la console de gestion AWS, vous pouvez facilement ajouter des réplicas en lecture à des instances de base de données existantes. Utilisez l'option « Create Read Replica » (Créer un réplica en lecture) correspondant à votre instance de base de données dans la Console de gestion AWS. Amazon RDS for MySQL, MariaDB et PostgreSQL vous permettent d'ajouter jusqu'à 15 réplicas en lecture à chaque instance de base de données. Amazon RDS for Oracle et SQL Server vous permettent d'ajouter jusqu'à 5 réplicas en lecture à chaque instance de base de données.

Amazon RDS for MySQL, MariaDB, PostgreSQL et Oracle vous proposent deux options de stockage de base de données SSD : usage général et IOPS provisionnés. Les réplicas en lecture de ces moteurs n'ont pas besoin d'utiliser le même type de stockage que leurs instances de base de données primaires. Vous pouvez optimiser vos performances ou vos dépenses en sélectionnant un autre type de stockage pour les réplicas en lecture. Pour en savoir plus, consultez la documentation des réplicas en lecture pour Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle et SQL Server ainsi qu'Amazon Aurora.

Réplicas en lecture, déploiements multi-AZ et déploiements multi-régions

Les réplicas en lecture d'Amazon RDS complètent les déploiements multi-AZ. Ces deux fonctionnalités conservent une copie supplémentaire de vos données, mais certaines différences subsistent :

Déploiements multi-AZ

Déploiements multi-régions

Réplicas en lecture

Objectif principal : haute disponibilité

Objectif principal : reprise après sinistre et performance locale

Objectif principal : capacité de mise à l'échelle

Non-Aurora : réplication synchrone. Aurora : réplication asynchrone

Réplication asynchrone

Réplication asynchrone

Non-Aurora : seule l'instance primaire est active. Aurora : toutes les instances sont actives

Toutes les régions sont accessibles et sont utilisables à des fins de lecture

Tous les réplicas en lecture sont accessibles et sont utilisables à des fins de dimensionnement de lecture

Non Aurora : les sauvegardes automatisées sont récupérées à partir de l'état de secours. Aurora : les sauvegardes automatisées sont récupérées à partir de la couche de stockage partagé

Des sauvegardes automatisées sont possible dans chaque région

Aucune sauvegarde configurée par défaut

Toujours sur au moins deux zones de disponibilité au sein d'une même région

Chaque région peut avoir un déploiement multi-AZ.

Peut se trouver dans une zone de disponibilité, sur plusieurs zones de disponibilité ou sur plusieurs régions

Non-Aurora : les mises à niveau des versions du moteur de base de données se font sur le primaire. Aurora : toutes les instances sont mises à jour ensemble

Non-Aurora : la mise à niveau de la version du moteur de base de données se fait de manière indépendante dans chaque région. Aurora : toutes les instances sont mises à jour ensemble.

Non-Aurora : la mise à niveau de la version du moteur de base de données est indépendante de l'instance source. Aurora : toutes les instances sont mises à jour ensemble.

Basculement automatique sur secours (non Aurora) ou en sur réplica en lecture (Aurora) lorsqu'un problème est détecté

Aurora permet la promotion d'une région secondaire au statut de région primaire

Peut être manuellement promu au statut d'instance de base de données autonome (non Aurora) ou d'instance principale (Aurora)

Vous pouvez combiner les réplicas en lecture avec d'autres fonctionnalités d'Amazon RDS pour profiter des avantages de chacun. Par exemple, vous pouvez configurer une base de données source sur multi-AZ pour profiter d'une haute disponibilité et créer un réplica en lecture (en zone mono-AZ) pour profiter d'une scalabilité en lecture. L'autre alternative consiste à utiliser Aurora Global Database pour répliquer des données de votre déploiement Aurora multi-AZ dans les autres régions.

Avec RDS for MySQL, MariaDB, PostgreSQL et Oracle, il est également possible de configurer le réplica en lecture sur multi-AZ, ce qui vous permet de l'utiliser comme cible de reprise après sinistre. En cas de promotion du réplica en lecture vers une base de données autonome, ce dernier sera directement configuré sur multi-AZ.