Présentation Création d'un réplica en lecture Promotion d'un réplica en lecture Supervision de la réplication en lecture

Utilisation des réplicas en lecture

Amazon RDS utilise la fonction de réplication intégrée des moteurs de base de données MariaDB, Microsoft MySQL Server, MySQL, Oracle et PostgreSQL pour créer un type particulier d'instance de base de données appelé réplica en lecture à partir d'une instance de base de données source. L'instance de base de données source devient l'instance de base de données principale. Les mises à jour apportées à l'instance de base de données principale sont copiées de façon asynchrone sur le réplica en lecture. Vous pouvez réduire la charge sur votre instance de base de données principale en acheminant les requêtes en lecture depuis vos applications vers le réplica en lecture. Les réplicas en lecture permettent une montée en puissance basée sur Elastic 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.

Note

Les informations suivantes s'appliquent à la création de réplicas en lecture Amazon RDS dans la même région AWS que l'instance de base de données source ou dans une autre région AWS. Les informations suivantes ne s'appliquent pas à la configuration de la réplication avec une instance qui s'exécute sur une instance Amazon EC2 ou sur site.

Lorsque vous créez un réplica en lecture, vous commencez par spécifier une instance de base de données existante en tant que 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. 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 dans l'instance de base de données source.

Note

Le moteur Oracle DB 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. L'utilisation principale des réplicas montés est la reprise après sinistre inter-région. Pour plus d'informations, consultez Utilisation des réplicas Oracle pour Amazon RDS.

Dans certains cas, un réplica en lecture se trouve dans une région AWS différente de celle 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 de sécurité AWS nécessaires pour activer le canal sécurisé, telles que l'ajout d'entrées de groupe de sécurité. Pour de plus amples informations sur les réplicas en lecture entre régions, veuillez consulter Création d'un réplica en lecture dans une autre région AWS.

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 une haute disponibilité. La réplication avec le réplica de secours est synchrone et le réplica de secours ne peut pas servir au trafic de lecture.

Configuration d'un réplica en lecture et d'un réplica de secours

Pour plus d'informations sur les réplicas de secours configurés pour une haute disponibilité, consultez Haute disponibilité (multi-AZ) pour Amazon RDS.

Les réplicas en lecture sont pris en charge par les moteurs de bases de données MariaDB, Microsoft SQL Server, MySQL, Oracle et PostgreSQL. Cette section fournit des informations générales sur l'utilisation des réplicas en lecture avec ces moteurs. Pour de plus amples informations sur l'utilisation de réplicas en lecture avec un moteur spécifique, veuillez consulter les sections suivantes :

Présentation des réplicas en lecture Amazon RDS

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'E/S 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'E/S, par exemple en raison d'une suspension des E/S 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.

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
PIOPS	100 Gio–32 Tio	PIOPS, GP2, Standard
GP2	100 Gio–32 Tio	PIOPS, GP2, Standard
GP2	<100 Gio	GP2, Standard
Standard	100 Gio - 6 Tio	PIOPS, GP2, Standard
Standard	<100 Gio	GP2, Standard

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.

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 MyDBInstance est répliqué sur ReadReplica1, vous ne pouvez pas configurer ReadReplica1 de façon à ce qu'il soit répliqué sur MyDBInstance. Pour MariaDB et MySQL, vous pouvez créer un réplica en lecture à partir d'un réplica en lecture existant. Par exemple, à partir de ReadReplica1, vous pouvez créer un nouveau réplica en lecture, comme ReadReplica2. Pour Oracle, PostgreSQL et SQL Server, vous ne pouvez pas créer de réplica en lecture à partir d'un réplica en lecture existant.

Si vous n'avez plus besoin de réplicas en lecture, vous pouvez les supprimer explicitement en utilisant les mêmes mécanismes que pour la suppression d'une instance de base de données. Si vous supprimez une instance de base de données source sans supprimer ses réplicas en lecture dans la même région AWS, chaque réplica en lecture est promu en instance de base de données autonome. Pour de plus amples informations sur la création d'une instance de base de données, veuillez consulter Suppression d'une instance DB. Pour de plus amples 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.

Si vous avez des réplicas en lecture entre régions, consultez Considérations liées à la réplication entre régions pour en savoir plus sur la suppression de l'instance de base de données source pour un réplica en lecture entre régions.

Différences entre les réplicas en lecture pour les différents moteurs de bases 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 de plus amples 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 `wal_keep_segments`, qui indique le nombre de fichiers WAL (write-ahead log) à conserver pour fournir les données aux réplicas en lecture. La valeur de ce paramètre spécifie le nombre de journaux à conserver.	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 vitesse à laquelle les sous-systèmes de disque se trouvent dans le réplica principal, le journal des transactions conserve les VLF jusqu'à ce que le réplica le plus lent l'ait sécurisé.
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. Vous pouvez autoriser des sauvegardes automatiques sur un réplica en lecture MySQL ou MariaDB.	Non. Vous ne pouvez pas créer d'instantanés manuels de Amazon RDS pour les réplicas en lecture Oracle ni activer les sauvegardes automatiques pour eux.	Oui, vous pouvez créer un instantané manuel d'un réplica en lecture PostgreSQL, mais vous ne pouvez pas activer les sauvegardes automatiques.	Non. Vous ne pouvez pas créer d'instantanés manuels de Amazon RDS pour les réplicas en lecture SQL Server ni activer les sauvegardes automatiques pour eux.
Est-il possible d'utiliser la réplication parallèle ?	Oui. MySQL versions 5.6 et ultérieures, ainsi que toutes les versions de MariaDB prises en charge 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 des réplicas Oracle pour Amazon RDS.	Non.	Non.

Création d'un réplica en lecture

Vous pouvez créer un réplica en lecture à partir d'une instance de base de données existante à l'aide de la AWS Management Console, de la AWS CLI ou de l'API RDS. Vous créez un réplica en lecture en spécifiant SourceDBInstanceIdentifier, qui est l'identifiant de l'instance de base de données source à partir de laquelle vous souhaitez répliquer les données.

Lorsque vous créez un réplica en lecture, Amazon RDS prend un instantané de votre instance de base de données source et commence la réplication. En conséquence, vous connaissez une brève suspension des E/S sur votre instance de base de données source pendant la réalisation de l'instantané de base de données.

Note

La suspension d'E/S dure généralement environ une minute. Vous pouvez éviter la suspension d'E/S si l'instance de base de données source est un déploiement multi-AZ, car dans ce cas l'instantané est pris à partir de l'instance de base de données secondaire.

Une transaction de longue durée active peut ralentir le processus de création du réplica en lecture. Nous vous recommandons d'attendre que les transactions de longue durée se terminent pour créer un réplica en lecture. Si vous créez plusieurs réplicas en lecture en parallèle à partir de la même instance de base de données source, Amazon RDS prend un seul instantané au début de la première action de création.

Lors de la création d'un réplica en lecture, il convient de prendre en considération plusieurs éléments. Tout d'abord, vous devez activer les sauvegardes automatiques sur l'instance de bases de données source en affectant à la période de rétention des sauvegardes une valeur différente de 0. Cette exigence s'applique également à un réplica en lecture qui serait l'instance de base de données source d'un autre réplica en lecture. Pour activer les sauvegardes automatiques sur un réplica en lecture TDS for MySQL version 5.6 et ultérieure, commencez par créer le réplica en lecture, puis modifiez-le pour activer les sauvegardes automatiques.

Note

Dans une région AWS, nous vous recommandons vivement de créer tous les réplicas en lecture dans le même cloud privé virtuel (VPC) basé sur Amazon VPC que l'instance de base de données source. Si vous créez un réplica en lecture dans un VPC différent de l'instance de base de données source, les plages d'adresses CIDR (classless inter-domain routing) peuvent se chevaucher entre le réplica et le système RDS. Le chevauchement CIDR rend le réplica instable, ce qui peut avoir un impact négatif sur les applications qui s'y connectent. Si vous recevez une erreur lors de la création du réplica en lecture, choisissez un autre groupe de sous-réseaux de base de données de destination. Pour plus d'informations, consultez Utilisation d'une instance de base de données dans un VPC.

Vous ne pouvez pas créer de réplica en lecture dans un compte AWS différent à partir de l'instance de base de données source.

Pour créer un réplica en lecture à partir d'une instance de base de données source

Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
Dans la panneau de navigation, choisissez Databases (Bases de données).
Sélectionnez l'instance de base de données que vous voulez utiliser comme source pour votre réplica en lecture.
Sous Actions, choisissez Créer des réplicas en lecture.
Sous Identifiant de l'instance DB, saisissez un nom pour le réplica en lecture.
Choisissez les spécifications de votre instance. Nous vous recommandons d'utiliser le même type de stockage et la même classe d'instance de base de données que l'instance de base de données source pour le réplica en lecture.
Pour Déploiement Multi-AZ, choisissez Oui afin de créer une instance de secours de votre réplica dans une autre zone de disponibilité pour la prise en charge du basculement pour le réplica.

Note

La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
Pour créer un réplica en lecture chiffré :
1. Choisissez Activer le chiffrement.
2. Pour Clé principale, choisissez l'identifiant de clé AWS Key Management Service (AWS KMS) de la clé CMK.
Note

L'instance de base de données source doit être chiffrée. Pour en savoir plus sur le chiffrement de l'instance de bases de données source, consultez Chiffrement des ressources Amazon RDS.
Choisissez d'autres options, telles que la scalabilité automatique du stockage.
Choisissez Créer un réplica en lecture.

Une fois le réplica en lecture créé, vous pouvez le voir sur la page Bases de données de la console RDS. Il affiche le réplica dans la colonne Rôle .

Pour créer un réplica en lecture à partir d'une instance de base de données source, utilisez la commande AWS CLI create-db-instance-read-replica. Cet exemple permet également la scalabilité automatique du stockage.

Exemple

Pour Linux, macOS ou Unix :


aws rds create-db-instance-read-replica \
    --db-instance-identifier myreadreplica \
    --source-db-instance-identifier mydbinstance \
    --max-allocated-storage 1000

Pour Windows :


aws rds create-db-instance-read-replica ^
    --db-instance-identifier myreadreplica ^
    --source-db-instance-identifier mydbinstance ^
    --max-allocated-storage 1000

Pour créer un réplica en lecture à partir d'une instance de base de données MySQL, MariaDB, Oracle, PostgreSQL ou SQL Server source, appelez l'opération CreateDBInstanceReadReplica de l'API Amazon RDS avec les paramètres requis suivants :

DBInstanceIdentifier
SourceDBInstanceIdentifier

Promotion d'un réplica en lecture en instance de bases de données autonome

Vous pouvez promouvoir un réplica en lecture an tant qu'une instance de base de données autonome. Lorsque vous effectuez la promotion d'un réplica en lecture, l'instance de bases de données est redémarrée avant de devenir disponible.

Il existe plusieurs raisons pour lesquelles vous pouvez souhaiter promouvoir un réplica en lecture en une instance de base de données autonome :

Exécution d'opérations DDL (MySQL et MariaDB uniquement) – Les opérations DDL, telles que la création ou la reconstruction d'index, peuvent prendre du temps et imposer une pénalité importante de performances à votre instance de base de données. Vous pouvez exécuter ces opérations sur un réplica en lecture MySQL ou MariaDB une fois que ce réplica en lecture est synchronisé avec son instance de bases de données principale. Ensuite, vous pouvez promouvoir le réplica en lecture et indiquer à vos applications d'utiliser l'instance promue.
Partitionnement – Le partitionnement incarne l'architecture « ne rien partager » et implique essentiellement la décomposition d'une grande base de données en plusieurs bases de données plus petites. Pour fractionner une base de données, l'une des méthodes consiste à fractionner les tables qui ne sont pas jointes dans la même requête sur différents hôtes. L'autre méthode consiste à dupliquer une table entre plusieurs hôtes, puis à utiliser un algorithme de hachage pour déterminer l'hôte qui reçoit une mise à jour donnée. Vous pouvez créer des réplicas en lecture correspondant à chacune de vos partitions (bases de données plus petites) et les promouvoir quand vous décidez de les convertir en partitions autonomes. Vous pouvez alors extraire l'espace clé (si vous fractionnez les lignes) ou la distribution des tables pour chaque partitionnement selon vos besoins.
Implémentation d'une récupération en cas de défaillance – Vous pouvez utiliser la promotion de réplica en lecture comme plan de récupération de données en cas de défaillance de l'instance de base de données principale. Cette approche complète la réplication synchrone, la détection automatique d'échec et le basculement.

Si vous êtes conscient des ramifications et des limitations de la réplication asynchrone et que vous souhaitez toujours utiliser la promotion de réplica en lecture pour la récupération des données, vous pouvez le faire. Pour cela, commencez par créer un réplica en lecture, puis surveillez l'instance de base de données principale pour détecter les pannes. En cas de panne, procédez comme suit :
1. Promouvez le réplica en lecture.
2. Dirigez le trafic de base de données vers l'instance de bases de données promue.
3. Créez un réplica en lecture de remplacement avec l'instance de base de données promue comme source.

Lorsque vous effectuez la promotion d'un réplica en lecture, la nouvelle instance de base de données créée conserve le groupe d'options et le groupe de paramètres de l'ancien réplica en lecture. Le processus de promotion peut prendre plusieurs minutes ou plus longtemps, selon la taille du réplica en lecture. Une fois le réplica en lecture promu en une nouvelle instance de base de données, il est similaire à toute autre instance de base de données. Par exemple, vous pouvez créer des réplicas en lecture à partir de la nouvelle instance de base de données et effectuer des opérations de restauration à un moment donné. Comme l'instance de bases de données promue n'est plus un réplica en lecture, vous ne pouvez pas l'utiliser comme cible de réplication. Si une instance de base de données source possède plusieurs réplicas en lecture, la promotion d'un des réplicas en lecture en instance de base de données n'a aucun effet sur les autres réplicas.

La durée de la sauvegarde dépend du nombre de modifications apportées à la base de données depuis la dernière sauvegarde. Si vous souhaitez promouvoir un réplica en lecture en instance autonome, nous vous recommandons d'activer les sauvegardes et d'en effectuer au moins une avant la promotion. En outre, vous ne pouvez pas promouvoir un réplica en lecture en une instance autonome lorsque son état est backing-up. Si vous avez activé des sauvegardes sur votre réplica en lecture, configurez la fenêtre de sauvegarde automatique afin que les sauvegardes quotidiennes n'interfèrent pas avec la promotion du réplica en lecture.

Les étapes suivantes montrent le processus général de promotion d'un réplica en lecture en instance de base de données :

Arrêtez l'écriture de toute transaction sur l'instance de base de données principale, puis attendez que toutes les mises à jour soient effectuées sur le réplica en lecture. Les mises à jour de la base de données ont lieu sur les réplica en lecture après avoir eu lieu sur l'instance de base de données principale, et cette latence de réplication peut varier de façon significative. Utilisez la métrique Replica Lag pour déterminer à quel moment toutes les mises à jour ont été effectuées sur le réplica en lecture.
Pour MySQL et MariaDB uniquement : si vous avez besoin d'apporter des modifications au réplica en lecture MySQL ou MariaDB, vous devez affecter au paramètre read_only la valeur 0 dans le groupe de paramètres de base de données du réplica en lecture. Vous pouvez alors effectuer toutes les opérations DDL requises, telles que la création d'index, sur le réplica en lecture. Les actions entreprises sur le réplica en lecture n'affectent pas la performance de l'instance de base de données principale.
Promouvez le réplica en lecture en utilisant l'option Promouvoir sur la console Amazon RDS, la commande de l'AWS CLI promote-read-replica, ou l'opération de l'API Amazon RDS PromoteReadReplica.

Note

Le processus de promotion dure quelques minutes. Lorsque vous promouvez un réplica en lecture, la réplication est arrêtée et le réplica en lecture est redémarré. Une fois le redémarrage terminé, le réplica en lecture est disponible en tant que nouvelle instance de base de données.
(Facultatif) Modifiez la nouvelle instance de base de données pour en faire un déploiement multi-AZ. Pour de plus amples informations, veuillez consulter Modification d'une instance de base de données Amazon RDS et Haute disponibilité (multi-AZ) pour Amazon RDS.

Pour promouvoir un réplica en lecture en tant qu'instance de base de données autonome

Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.
Dans la console Amazon RDS, choisissez Bases de données.

Le volet Bases de données s'affiche. Chaque réplica en lecture affiche Réplica dans la colonne Rôle.
Choisissez le réplica en lecture que vous voulez promouvoir.
Pour Actions, choisissez Promote (Promouvoir).
Dans la page Promouvoir le réplica en lecture, saisissez la période de rétention des sauvegardes et la fenêtre de sauvegarde pour l'instance de base de données nouvellement promue.
Lorsque les paramètres vous conviennent, choisissez Continue.
Dans la page de confirmation, choisissez Promouvoir le réplica en lecture.

Pour promouvoir un réplica en lecture en tant qu'instance de base de données autonome, utilisez la commande AWS CLI de lapromote-read-replica.

Exemple

Pour Linux, macOS ou Unix :


aws rds promote-read-replica \
    --db-instance-identifier myreadreplica

Pour Windows :


aws rds promote-read-replica ^
    --db-instance-identifier myreadreplica

Pour promouvoir un réplica en lecture en tant qu'instance de base de données autonome, appelez l'opération PromoteReadReplica de l'API Amazon RDS avec le paramètre requis DBInstanceIdentifier.

Supervision de la réplication en lecture

Vous pouvez superviser le statut d'un réplica en lecture de différentes manières. La console Amazon RDS affiche le statut d'un réplica en lecture dans la section Disponibilité et durabilité des détails du réplica en lecture. Pour consulter les détails d'un réplica en lecture, cliquez sur son nom dans la liste des instances de la console Amazon RDS.

Vous pouvez également consulter le statut d'un réplica en lecture à l'aide de la commande de l'AWS CLI describe-db-instances ou de l'opération de l'API Amazon RDS DescribeDBInstances.

Le statut d'un réplica en lecture peut avoir les valeurs suivantes :

replicating (réplication en cours) – Le réplica en lecture réplique correctement.
réplication dégradée (SQL Server uniquement)– Les réplicas reçoivent des données de l'instance principale, mais une ou plusieurs bases de données peuvent ne pas recevoir de mises à jour. Cela peut se produire, par exemple, lorsqu'un réplica est en train de configurer des bases de données nouvellement créées.

L'état ne passe pas de replication degraded à error, à moins qu'une erreur ne se produise pendant l'état dégradé.
error (erreur) – Une erreur s'est produite dans le cadre de la réplication. Examinez le champ Replication Error (Erreur de réplication) dans la console Amazon RDS ou le journal des événements pour déterminer l'erreur exacte. Pour plus d'informations sur la résolution d'une erreur de réplication, consultez Résolution d'un problème de réplica en lecture MySQL.
terminated (arrêté) (MariaDB, MySQL ou PostgreSQL uniquement) – La réplication est arrêtée. Cela se produit si la réplication est arrêtée pendant plus de trente jours consécutifs, manuellement ou en raison d'une erreur de réplication. Dans ce cas, Amazon RDS met fin à la réplication entre l'instance de base de données principale et tous les réplicas en lecture. Amazon RDS fait cela pour éviter l'augmentation des besoins en stockage sur l'instance de base de données source et de longs délais de basculement.

Une réplication interrompue peut affecter le stockage, car les journaux peuvent croître en taille et en nombre en raison du volume élevé des messages d'erreur consignés dans le journal. Une réplication interrompue peut également affecter la récupération en cas de défaillance en raison du temps dont a besoin Amazon RDS pour conserver et traiter le grand nombre de journaux au cours de la récupération.
stopped (interrompue) (MariaDB ou MySQL uniquement) – La réplication s'est interrompue en raison d'une demande initiée par le client.
replication stop point set (point d'arrêt de réplication réglé) (MySQL uniquement) – Un point d'arrêt de réplication a été réglé par le client à l'aide de la procédure stockée mysql.rds_start_replication_until et la réplication est en cours.
replication stop point reached (point d'arrêt de réplication atteint) (MySQL uniquement) – Un point d'arrêt de réplication a été réglé par le client à l'aide de la procédure stockée mysql.rds_start_replication_until et la réplication est arrêtée, car le point d'arrêt est atteint.

Vous pouvez voir où une instance de base de données est répliquée et, le cas échéant, vérifier son état de réplication. Sur la page Bases de données de la console RDS, elle affiche Primaire dans la colonne Rôle . Choisissez son nom d'instance de base de données. Sur sa page détaillée, dans l'onglet Connectivité et sécurité, son état de réplication se trouve sous Réplication.

Surveillance du retard de réplication

Vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS ReplicaLag.

Pour MySQL et MariaDB, la métrique ReplicaLag contient la valeur du champ Seconds_Behind_Master de la commande SHOW REPLICA STATUS. Les causes courantes du retard de réplication pour MySQL et MariaDB sont les suivantes :

Une indisponibilité du réseau.
L'écriture dans des tables avec des index sur un réplica en lecture. Si le paramètre read_only n'a pas pour valeur 0 sur le réplica en lecture, il peut interrompre la réplication.
Utilisation d'un moteur de stockage non transactionnel tel que MyISAM. La réplication est prise en charge uniquement pour le moteur de stockage InnoDB sur MySQL et pour le moteur de stockage XtraDB sur MariaDB.

Note

Les versions précédentes de MariaDB et MySQL utilisaient SHOW SLAVE STATUS à la place de SHOW REPLICA STATUS. Si vous utilisez une version de MariaDB antérieure à la version 10.5 ou MySQL antérieure à la version 8.0.23, utilisez alors SHOW SLAVE STATUS.

Lorsque la métrique ReplicaLag atteint 0, le réplica a rattrapé l'instance de bases de données principale. Si la métrique ReplicaLag retourne -1, la réplication n'est actuellement pas active. ReplicaLag = -1 est équivalent à Seconds_Behind_Master = NULL.

Pour Oracle, la métrique ReplicaLag correspond à la somme de la valeur Apply Lag et à la différence entre la durée actuelle et la valeur DATUM_TIME du retard appliqué. La valeur DATUM_TIME correspond à la dernière heure à laquelle le réplica en lecture a reçu des données de son instance de base de données source. Pour de plus amples informations, veuillez consulter V$DATAGUARD_STATS dans la documentation d'Oracle.

Pour SQL Server, la métrique ReplicaLag correspond au décalage maximal des bases de données qui ont pris du retard, en secondes. Par exemple, si vous avez deux bases de données qui accusent respectivement un retard de 5 secondes et 10 secondes, alors ReplicaLag a pour valeur 10 secondes. La métrique ReplicaLag renvoie la valeur de la requête suivante.


select ag.name name, MAX(hdrs.secondary_lag_seconds) max_lag from sys.dm_hadr_database_replica_state

Pour de plus amples informations, veuillez consulter secondary_lag_seconds dans la documentation Microsoft.

ReplicaLag renvoie -1 si RDS ne peut pas déterminer le retard, par exemple lors de la configuration du réplica, ou lorsque le réplica en lecture est à l'état error.

Note

Les nouvelles bases de données ne sont pas incluses dans le calcul du retard tant qu'elles ne sont pas accessibles sur le réplica en lecture.

Pour PostgreSQL, la métrique ReplicaLag renvoie la valeur de la requête suivante.


SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS reader_lag

PostgreSQL versions 9.5.2 et ultérieures utilise des emplacements physiques de réplication pour gérer la rétention WAL (Write Ahead Log) sur l'instance source. Pour chaque instance de réplica en lecture entre régions, Amazon RDS crée un emplacement de réplication physique et l'associe à l'instance. Deux métriques Amazon CloudWatch, Oldest Replication Slot Lag et Transaction Logs Disk Usage, indiquent le retard du dernier réplica en termes de données WAL reçues et le volume de stockage utilisé pour les données WAL. La valeur Transaction Logs Disk Usage peut considérablement augmenter lorsqu'un réplica en lecture entre régions présente un retard important.

Pour de plus amples informations sur la surveillance d'un cluster de bases de données avec CloudWatch, veuillez consulter Surveillance des métriques Amazon RDS avec Amazon CloudWatch.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Redémarrage d'une instance DB

Création d'un réplica en lecture dans une autre région AWS