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 des réplicas en lecture d'instance de base de données
Un réplica en lecture est une copie en lecture seule d'une instance de base de données. Vous pouvez réduire la charge sur votre instance de base de données principale en acheminant les requêtes depuis vos applications vers le réplica en lecture. Ainsi, vous pouvez effectuer une montée en puissance élastique au-delà des contraintes de capacité d'une seule instance de base de données dans le cas de charges de travail de base de données à lecture intensive.
Pour créer un réplica en lecture à partir d'une instance de base de données source, Amazon RDS utilise les fonctions de réplication intégrées du moteur de base de données. Pour plus d'informations sur l'utilisation de réplicas en lecture avec un moteur spécifique, veuillez consulter les sections suivantes :
Après que vous avez créé un réplica en lecture à partir d'une instance de base de données source, la source devient l'instance de base de données principale. Lorsque vous apportez des mises à jour à l'instance de base de données principale, Amazon RDS les copie de manière asynchrone vers le réplica en lecture. Le schéma suivant montre une instance de base de données source effectuant la réplication vers un réplica en lecture dans une zone de disponibilité (AZ) différente. Les clients ont un accès en lecture/écriture à l'instance de base de données principale et un accès en lecture seule à la réplique.
Les répliques de lecture sont facturées en tant qu'instances de base de données standard aux mêmes taux que la classe d'instance de base de données utilisée pour la réplique. Le transfert de données effectué lors de la réplication de données entre l'instance de base de données source et une réplique en lecture au sein de celle-ci Région AWS ne vous est pas facturé. Pour plus d’informations, consultez Coûts de la réplication entre régions et Facturation d'instance de base de données pour Amazon.
Rubriques
Présentation des réplicas en lecture Amazon RDS
Les sections ci-dessous traitent des réplicas en lecture d'une instance de base de données. Pour plus d'informations sur les réplicas en lecture d'un cluster de bases de données multi-AZ, consultez Utilisation de répliques de lecture de clusters de bases de données multi-AZ pour Amazon RDS.
Rubriques
Cas d'utilisation pour les réplicas en lecture
Le déploiement d'un ou de plusieurs réplicas en lecture pour une instance de bases de données source donnée peut être judicieux dans divers scénarios, notamment dans les suivants :
-
Dimensionnement au-delà de la capacité de calcul ou d'I/O d'une instance de bases de données individuelle pour des charges de travail de base de données à lecture intensive. Vous pouvez diriger ce trafic en lecture excessif vers un ou plusieurs réplicas en lecture.
-
Service du trafic en lecture alors que l'instance de bases de données source est indisponible. Dans certains, cas, votre instance de bases de données source ne peut pas prendre en charge les demandes d'I/O, par exemple en raison d'une suspension des I/O pour des sauvegardes ou la maintenance planifiée. Vous pouvez alors diriger le trafic de lecture vers vos réplicas en lecture. Dans ce cas d'utilisation, gardez à l'esprit que les données sur le réplica en lecture peuvent être « périmées » car l'instance de bases de données source est indisponible.
-
Scénarios de création de rapports commerciaux ou d'entreposage de données, dans lesquels vous pouvez souhaiter que les requêtes de rapports commerciaux s'exécutent sur un réplica en lecture, plutôt que sur votre instance de bases de données de production.
-
Mise en œuvre de la reprise après sinistre. Vous pouvez effectuez la promotion d'un réplica en lecture en instance autonome comme plan de reprise après sinistre en cas de défaillance de l'instance de base de données principale.
Fonctionnement des réplicas en lecture
Lorsque vous créez une réplique en lecture, vous spécifiez une instance de base de données existante comme source. Ensuite, Amazon RDS prend un instantané de l'instance source et crée une instance en lecture seule à partir de celui-ci. Amazon RDS utilise la méthode de réplication asynchrone pour le moteur de base de données afin de mettre à jour le réplica en lecture chaque fois qu'une modification est apportée à l'instance de base de données principale.
Le réplica en lecture fonctionne comme une instance de bases de données qui autorise uniquement les connexions en lecture seule. Le moteur de base de données RDS for Oracle fait exception, car il prend en charge les bases de données de réplica en mode monté. Un réplica monté n'accepte pas les connexions utilisateur et ne peut donc pas servir de charge de travail en lecture seule. Les répliques montées dans RDS pour Oracle sont principalement utilisées pour la reprise après sinistre entre régions. Pour de plus amples informations, veuillez consulter Utilisation de réplicas en lecture pour Amazon RDS for Oracle.
Les applications se connectent à un réplica en lecture de la même façon qu'à toute instance de base de données. Amazon RDS réplique toutes les bases de données à partir de l'instance de base de données source.
Vous devez créer manuellement des répliques de lecture. RDS ne prend pas en charge le dimensionnement automatique des répliques de lecture, qui consiste à ajouter ou à supprimer automatiquement des répliques de lecture lorsque la demande de lecture change.
Réplicas en lecture dans un déploiement multi-AZ
Vous pouvez configurer un réplica en lecture pour une instance de base de données disposant également d'un réplica de secours configuré pour la haute disponibilité dans un déploiement multi-AZ. La réplication avec le réplica de secours est synchrone. Contrairement à un réplica en lecture, un réplica de secours ne peut pas servir au trafic de lecture.
Dans le scénario suivant, les clients ont un accès en lecture/écriture à une instance de base de données principale dans une zone de disponibilité. L'instance principale copie les mises à jour de manière asynchrone vers un réplica en lecture dans une deuxième zone de disponibilité et les copie également de manière synchrone vers un réplica de secours dans une troisième zone de disponibilité. Les clients possèdent un accès en lecture uniquement au réplica en lecture.
Pour plus d'informations sur les réplicas de secours configurés pour une haute disponibilité, consultez Configuration et gestion d'un déploiement multi-AZ pour Amazon RDS.
Réplicas en lecture entre Régions
Dans certains cas, une réplique en lecture réside dans une instance de base de données Région AWS différente de son instance de base de données principale. Dans ces cas, Amazon RDS configure un canal de communication sécurisé entre l'instance de base de données principale et le réplica en lecture. Amazon RDS établit toutes les configurations AWS de sécurité nécessaires pour activer le canal sécurisé, telles que l'ajout d'entrées de groupe de sécurité. Pour plus d'informations sur les réplicas en lecture entre régions, veuillez consulter Création d'une réplique de lecture dans un autre Région AWS.
Les informations de ce chapitre s'appliquent à la création de répliques de lecture Amazon RDS, soit dans la même Région AWS instance de base de données source, soit dans une instance séparée. Région AWS Les informations suivantes ne s'appliquent pas à la configuration de la réplication avec une instance exécutée sur une EC2 instance Amazon ou sur site.
Différences entre les réplicas en lecture pour les moteurs de base de données
Dans la mesure où les moteurs de bases de données Amazon RDS implémentent la réplication différemment, plusieurs différences importantes sont à noter :
| Fonction ou comportement | MySQL et MariaDB | Oracle | PostgreSQL | SQL Server |
|---|---|---|---|---|
|
Quelle est la méthode de réplication ? |
Réplication logique |
Réplication physique |
Réplication physique |
Réplication physique |
|
Comment les journaux de transactions sont-ils purgés ? |
RDS for MySQL et RDS for MariaDB conservent les journaux binaires qui n'ont pas été appliqués. |
Si une instance de base de données principale ne possède aucun réplica en lecture entre régions, Amazon RDS for Oracle conserve un minimum de deux heures de journaux de transactions sur l'instance de base de données source. Les journaux sont purgés de l'instance de base de données source au bout de deux heures ou une fois que le paramètre d'heures de conservation du journal d'archive est passé, le plus long des deux. Les journaux sont purgés du réplica en lecture une fois que le paramètre d'heures de conservation du journal d'archive est passé, uniquement s'ils ont été appliqués correctement à la base de données. Dans certains cas, une instance de base de données principale peut avoir un ou plusieurs réplicas en lecture entre régions. Dans ce cas, Amazon RDS for Oracle conserve les journaux de transaction sur l'instance de base de données source jusqu'à ce qu'ils aient été transmis et appliqués à tous les réplicas en lecture entre régions. Pour plus d'informations sur la définition des heures de conservation des journaux d'archivage, veuillez consulter Conservation des journaux redo archivés. |
PostgreSQL dispose du paramètre |
Le fichier journal virtuel (VLF) du fichier journal des transactions sur le réplica principal peut être tronqué une fois qu'il n'est plus nécessaire pour les réplicas secondaires. Le VLF ne peut être marqué comme inactif que lorsque les enregistrements de journaux ont été sécurisés dans les réplicas. Quelle que soit la rapidité avec laquelle les sous-systèmes de disque se trouvent dans la réplique principale, le journal des transactions le conservera VLFs jusqu'à ce que la réplique la plus lente l'ait durcie. |
|
Est-il possible de rendre un réplica accessible en écriture ? |
Oui. Vous pouvez permettre au réplica en lecture MySQL ou MariaDB d'être accessible en écriture. |
Non. Un réplica en lecture Oracle est une copie physique et Oracle n'autorise pas les écritures dans un réplica en lecture. Vous pouvez promouvoir un réplica en lecture afin de le rendre inscriptible. Le réplica en lecture promu a les données répliquées jusqu'au moment où la demande a été faite pour le promouvoir. |
Non. Un réplica en lecture PostgreSQL est une copie physique et PostgreSQL ne permet pas de rendre accessible en écriture un réplica en lecture. |
Non. Un réplica en lecture SQL Server est une copie physique et n'autorise pas les écritures. Vous pouvez promouvoir un réplica en lecture afin de le rendre inscriptible. Le réplica en lecture promu a les données répliquées jusqu'au moment où la demande a été faite pour le promouvoir. |
|
Des sauvegardes peuvent-elles être effectuées sur le réplica ? |
Oui. Les sauvegardes automatiques et les instantanés manuels sont pris en charge sur les réplicas en lecture RDS for MySQL ou RDS for MariaDB. |
Oui. Les sauvegardes automatiques et les instantanés manuels sont pris en charge sur les réplicas en lecture RDS for Oracle. |
Oui, vous pouvez créer un instantané manuel de réplicas en lecture RDS for PostgreSQL. Les sauvegardes automatiques pour les réplicas en lecture sont prises en charge pour RDS for PostgreSQL 14.1 et versions ultérieures uniquement. Vous ne pouvez pas activer les sauvegardes automatiques pour les réplicas en lecture PostgreSQL pour les versions de RDS for PostgreSQL antérieures à 14.1. Pour RDS for PostgreSQL 13 et versions antérieures, créez un instantané à partir d'un réplica en lecture si vous souhaitez en obtenir une sauvegarde. |
Non. Les sauvegardes automatiques et les instantanés manuels ne sont pas pris en charge sur les réplicas en lecture RDS for SQL Server. |
|
Est-il possible d'utiliser la réplication parallèle ? |
Oui. Toutes les versions prises en charge de MariaDB et MySQL autorisent les threads de réplication parallèles. |
Oui. Les données des journaux redo sont toujours transmises en parallèle de la base de données principale vers tous ses réplicas en lecture. |
Non. PostgreSQL dispose d'un processus unique de réplication. |
Oui. Les données des journaux redo sont toujours transmises en parallèle de la base de données principale vers tous ses réplicas en lecture. |
|
Pouvez-vous maintenir un réplica dans un état monté plutôt qu'en lecture seule ? |
Non. |
Oui. L'utilisation principale des réplicas montés est la reprise après sinistre inter-région. Une licence Active Data Guard n'est pas requise pour les réplicas montés. Pour plus d'informations, consultez Utilisation de réplicas en lecture pour Amazon RDS for Oracle. |
Non. |
Non. |
Types de stockage de réplica en lecture
Par défaut, un réplica en lecture est créé avec le même type de stockage que l'instance de bases de données source. Toutefois, vous pouvez créer un réplica en lecture disposant d'un autre type de stockage que l'instance de bases de données source, en fonction des options répertoriées dans le tableau suivant.
| Type de stockage de l'instance de bases de données source | Allocation de stockage d'instance de bases de données source | Options de type de stockage du réplica en lecture |
|---|---|---|
| IOPS provisionnés | 100 Gio–64 Tio | IOPS provisionnés, usage général, magnétique |
| Usage général | 100 Gio–64 Tio | IOPS provisionnés, usage général, magnétique |
| Usage général | <100 Gio | Usage général, magnétique |
| Magnétique | 100 Gio - 6 Tio | IOPS provisionnés, usage général, magnétique |
| Magnétique | <100 Gio | Usage général, magnétique |
Note
Lorsque vous augmentez le stockage alloué d'un réplica en lecture, il doit être d'au moins 10 %. Si vous tentez d'augmenter la valeur de moins de 10 %, une erreur s'affiche.
Restrictions relatives à la création d'un réplica à partir d'un réplica
Amazon RDS ne prend pas en charge la réplication circulaire. Vous ne pouvez pas configurer une instance de base de données afin de l'utiliser comme source de réplication pour une instance de base de données existante. Vous pouvez uniquement créer un nouveau réplica en lecture à partir d'une instance de base de données existante. Par exemple, si MySourceDBInstance est répliqué sur ReadReplica1, vous ne pouvez pas configurer ReadReplica1 de façon à ce qu'il soit répliqué sur MySourceDBInstance.
Pour RDS for MariaDB et RDS for MySQL, et pour certaines versions de RDS for PostgreSQL, vous pouvez créer un réplica en lecture à partir d'un réplica en lecture existant. Par exemple, vous pouvez créer un nouveau réplica en lecture ReadReplica2 à partir d'un réplica ReadReplica1 existant. Pour RDS for Oracle et RDS for SQL Server, vous ne pouvez pas créer un réplica en lecture à partir d'un réplica en lecture existant.
Considérations relatives à la suppression de réplicas
RDS ne prend pas en charge le dimensionnement automatique des répliques de lecture. Ainsi, RDS n'augmentera pas le nombre de répliques en cas de demande ni n'augmentera ou ne diminuera le nombre de répliques lorsque la demande diminue. Si vous n'avez plus besoin de répliques de lecture, supprimez-les manuellement en utilisant les mêmes mécanismes que ceux utilisés pour supprimer une instance de base de données. Si vous supprimez une instance de base de données source sans supprimer ses répliques de lecture Région AWS, chaque réplique est promue en instance de base de données autonome.
Pour plus d'informations sur la création d'une instance de base de données, veuillez consulter Suppression d'une instance DB. Pour plus d'informations sur la promotion d'un réplica en lecture, veuillez consulter Promotion d'un réplica en lecture en instance de bases de données autonome. Pour plus d'informations sur la suppression de l'instance de base de données source pour une réplique de lecture entre régions, consultezConsidérations liées à la réplication entre régions.
