Documentation AWS » Amazon Relational Database Service (RDS) » Guide de l'utilisateur » instances de bases de données Amazon RDS » Utilisation des réplicas en lecture

Filter View: All Console AWS CLI API RDS

Utilisation des réplicas en lecture

Amazon RDS utilise aussi la fonctionnalité de réplication intégrée des moteurs de base de données PostgreSQL, MySQL et MariaDB pour créer un type particulier d'instance DB appelé réplica en lecture à partir d'une instance DB source. Les mises à jour apportées à l'instance de bases de données source sont copiées de façon asynchrone sur le réplica en lecture. Vous pouvez réduire la charge sur votre instance de bases de données source en acheminant les requêtes en lecture depuis vos applications vers le réplica en lecture. Les réplicas en lecture permettent un dimensionnement basé sur Elastic au-delà des contraintes de capacité d'une seule instance de bases 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 bases 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 bases de données existante en tant que source. Ensuite, Amazon RDS prend un instantané de l'instance de source et crée une instance en lecture seule à partir de l'instantané. Amazon RDS utilise ensuite la méthode de réplication asynchrone pour le moteur de base de données afin de mettre à jour le réplica en lecture lorsqu'un changement se produit dans l'instance de base de données source. 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.

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 source. Dans ces cas, Amazon RDS configure un canal de communication sécurisé entre l'instance de bases de données source et un réplica en lecture. Amazon RDS règle toute configuration de sécurité AWS nécessaire pour activer le canal sécurisé, tel que l'ajout des entrées de groupe de sécurité.

Les réplicas en lecture sont pris en charge par les moteurs MariaDB, MySQL et PostgreSQL. Cette section fournit des informations générales sur l'utilisation des réplicas en lecture avec ces trois moteurs. Pour plus d'informations sur l'utilisation de réplicas en lecture avec un moteur spécifique, consultez les sections suivantes :

• Utilisation de réplicas en lecture MySQL

• Utilisation de réplicas en lecture MariaDB

• Utilisation des réplicas en lecture Oracle pour Amazon RDS

• Utilisation de réplicas en lecture PostgreSQL

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 principale.

• 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.

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

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, MySQL et PostgreSQL, 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, vous ne pouvez pas créer de réplica en lecture à partir d'un réplica en lecture existant.

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
Quelle est la méthode de réplication ?	Réplication logique	Réplication physique	Réplication physique
Comment les journaux de transactions sont-ils purgés ?	Amazon RDS MySQL and MariaDB conservent les journaux binaires qui n'ont pas été appliqués.	Amazon RDS pour 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 la source au bout de deux heures ou une fois que le paramètre archivelog retention hours est passé, le plus long des deux. Les journaux sont purgés du réplica en lecture une fois que le paramètre archivelog retention hours est passé uniquement s'ils ont été appliqués correctement à la base de données. Pour de plus amples informations sur la configuration de archivelog retention hours, veuillez consulter Conservation des journaux redo archivés.	PostgreSQL a un 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.
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.
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.
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és des jouurnaux redo sont toujours transmises en parallèle de la base de données source vers tous ses réplicas en lecture.	Non. PostgreSQL dispose d'un processus unique de réplication.

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 MySQL, MariaDB ou PostgreSQL existante à l'aide de la AWS Management Console, de l'AWS CLI ou de l'API AWS. Vous créez un réplica en lecture en spécifiant SourceDBInstanceIdentifier, qui est l'identifiant d'instance de bases de données de l'instance de bases 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 base de données 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. 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 bases 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 bases de données source d'un autre réplica en lecture. Pour les instances de base de données MySQL, les sauvegardes automatiques sont prises en charge uniquement pour les réplicas en lecture exécutant une version de MySQL 5.6 ou ultérieure, mais non pour les versions de MySQL 5.5. Pour activer les sauvegardes automatiques sur un Amazon RDS MySQL version 5.6 ou ultérieure et plus tard un réplica en lecture, commencez par créer le réplica en lecture, puis modifiez le réplica en lecture pour activer les sauvegardes automatiques.

Note

Au sein d’une région AWS, tous les réplicas en lecture doivent être créés dans le même Amazon VPC que l’instance de base de données source, même si l’appairage VPC est configuré dans la région.

Console

Pour créer un réplica en lecture à partir d'une instance de bases de données MySQL, MariaDB ou PostgreSQL source

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans la panneau de navigation, choisissez Databases (Bases de données).

3. Choisissez l'instance de base de données MySQL, MariaDB ou PostgreSQL que vous souhaitez utiliser comme source pour un réplica en lecture.

4. Sous Actions, choisissez Créer des réplicas en lecture.

5. Choisissez les spécifications de l'instance que vous souhaitez utiliser. 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. 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 soit ou non une instance de base de données multi-AZ.

6. Choisissez les paramètres que vous souhaitez utiliser. Sous Identifiant de l'instance DB, saisissez un nom pour le réplica en lecture. Ajustez les autres paramètres selon les besoins.

7. Choisissez les autres paramètres que vous voulez utiliser.

8. Choisissez Créer un réplica en lecture.

AWS CLI

Pour créer un réplica en lecture à partir d'une instance de base de données source MySQL, MariaDB ou PostgreSQL, utilisez la commande create-db-instance-read-replica de l'AWS CLI.

Exemple

Pour Linux, OS X ou Unix :

aws rds create-db-instance-read-replica \
    --db-instance-identifier myreadreplica \
    --source-db-instance-identifier mydbinstance

Pour Windows :

aws rds create-db-instance-read-replica ^
    --db-instance-identifier myreadreplica ^
    --source-db-instance-identifier mydbinstance

API RDS

Pour créer un réplica en lecture à partir d'une instance de bases de données MySQL, MariaDB ou PostgreSQL source, appelez la fonction d'API Amazon RDS CreateDBInstanceReadReplica.

https://rds.amazonaws.com/
	?Action=CreateDBInstanceReadReplica
	&DBInstanceIdentifier=myreadreplica
	&SourceDBInstanceIdentifier=mydbinstance
	&Version=2012-01-15						
	&SignatureVersion=2
	&SignatureMethod=HmacSHA256
	&Timestamp=2012-01-20T22%3A06%3A23.624Z
	&AWSAccessKeyId=<AWS Access Key ID>
	&Signature=<Signature>

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

Vous pouvez promouvoir un réplica en lecture MySQL, MariaDB ou PostgreSQL en 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 source. 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 source. 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 procéder comme suit. Pour cela, commencez par créer un réplica en lecture, puis surveillez l'instance de bases de données source 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 bases 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 qui est créée conserve la période de rétention des sauvegardes, la fenêtre de sauvegarde et le groupe de paramètres de l'ancienne source de 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 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 bases de données source possède plusieurs réplicas en lecture, la promotion d'un des réplicas en lecture en instance de bases 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. De plus, un réplica en lecture ne peut pas être promu en instance autonome lorsqu'il est en statut backing-up. Si vous avez activé des sauvegardes sur votre replica en lecture, configurez la fenêtre de sauvegarde automatique afin que les sauvegardes quotidiennes n'interfèrent pas avec la promotion du replica 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 :

1. Arrêtez l'écriture de toute transaction sur l'instance de bases de données source du réplica en lecture, 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 bases de données source, et cette latence de réplication peut varier de façon significative. Utilisez la métrique Retard du réplica pour déterminer à quel moment toutes les mises à jour ont été effectuées sur le réplica en lecture.

2. 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 DB pour le 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 bases de données source.

3. Promouvez le réplica en lecture en utilisant l'option Promote Read Replica (Promouvoir le réplica en lecture) sur la console Amazon RDS, la commande AWS CLI promote-read-replica ou l'opération d'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.

4. (Facultatif) Modifiez la nouvelle instance de base de données pour en faire un déploiement multi-AZ. Pour plus d'informations, consultez Modification d'une instance de base de données Amazon RDS et Haute disponibilité (multi-AZ) pour Amazon RDS.

Console

Pour promouvoir un réplica en lecture en instance de bases de données

1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. 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.

3. Choisissez le réplica en lecture que vous voulez promouvoir.

4. Sous Actions, choisissez Promouvoir le réplica en lecture.

5. 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 la nouvelle instance de base de données promue.

6. Lorsque les paramètres vous conviennent, choisissez Continue.

7. Dans la page de confirmation, choisissez Promouvoir le réplica en lecture.

AWS CLI

Pour promouvoir un réplica en lecture en instance de bases de données, utilisez la commande promote-read-replica de l'AWS CLI.

Exemple

Pour Linux, OS X ou Unix :

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

Pour Windows :

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

API RDS

Pour promouvoir un réplica en lecture en instance de bases de données, appelez PromoteReadReplica.

https://rds.amazonaws.com/
	?Action=PromoteReadReplica
	&DBInstanceIdentifier=myreadreplica
	&Version=2012-01-15						
	&SignatureVersion=2
	&SignatureMethod=HmacSHA256
	&Timestamp=2012-01-20T22%3A06%3A23.624Z
	&AWSAccessKeyId=<AWS Access Key ID>
	&Signature=<Signature>

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

Avec Amazon RDS, vous pouvez créer un réplica en lecture MySQL, PostgreSQL ou MariaDB dans une autre région AWS que celle de l'instance de bases de données source. Vous créez un réplica en lecture pour effectuer les opérations suivantes :

• Améliorer vos capacités de reprise après sinistre.

• Mettre à l'échelle des opérations de lecture dans une région AWS plus proche de vos utilisateurs.

• Faciliter la migration d'un centre de données d'une région AWS vers un centre de données d'une autre région AWS.

La création d'un réplica en lecture MySQL, PostgreSQL ou MariaDB dans une région AWS différente de celle de l'instance source est similaire à la création d'un réplica dans la même région AWS. Pour créer un réplica en lecture entre régions, vous pouvez utiliser l’AWS Management Console, exécuter la commande create-db-instance-read-replica ou appeler l'opération d'API CreateDBInstanceReadReplica.

Pour créer un réplica en lecture chiffré dans une autre région AWS que celle de l'instance de bases de données source, cette instance de bases de données source doit être chiffrée.

Ci-après, vous pouvez trouver des informations qui expliquent comment créer un réplica en lecture à partir d'une instance de bases de données MySQL, MariaDB ou PostgreSQL source dans une autre région AWS.

Console

Vous pouvez créer un réplica en lecture entre régions à l'aide de l'AWS Management Console.

Pour créer un réplica en lecture entre régions avec la console

1. Connectez-vous à AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

2. Dans la panneau de navigation, choisissez Databases (Bases de données).

3. Choisissez l'instance de base de données MySQL, MariaDB ou PostgreSQL que vous souhaitez utiliser comme source d'un réplica en lecture, puis choisissez Créer des réplicas en lecture sous Actions. L'instance de bases de données source doit être chiffrée pour pouvoir créer un réplica en lecture chiffré. Pour en savoir plus sur le chiffrement de l'instance de bases de données source, consultez Chiffrement des ressources Amazon RDS.

4. Choisissez les spécifications de l'instance que vous souhaitez utiliser. Nous vous recommandons d'utiliser le même type de stockage et la même classe d'instance de bases de données pour le réplica en lecture.

5. Choisissez les autres paramètres que vous voulez utiliser :

   • Sous Identifiant de l'instance DB, saisissez un nom pour le réplica en lecture.

   • Dans la section Réseau et sécurité, choisissez une valeur pour Designation region (Région de désignation) et Designation DB subnet group (Groupe de sous-réseaux DB de désignation).

   • Pour créer un réplica en lecture chiffré dans une autre région AWS, choisissez Activer le chiffrement, et choisissez Clé principale. Pour Clé principale, choisissez l'identifiant de clé AWS Key Management Service (AWS KMS) de la région AWS de destination.

   • Choisissez les autres paramètres que vous voulez utiliser.

6. Choisissez Créer un réplica en lecture.

AWS CLI

Pour créer un réplica en lecture à partir d'une instance de base de données MySQL, MariaDB ou PostgreSQL source dans une autre région AWS, vous pouvez utiliser la commande create-db-instance-read-replica. Dans ce cas, vous utilisez create-db-instance-read-replica à partir de la région AWS où vous voulez placer le réplica en lecture et vous spécifiez l'Amazon Resource Name (ARN) pour l'instance de base de données source. Un ARN identifie de façon unique une ressource créée dans Amazon Web Services.

Par exemple, si votre instance de bases de données se trouve dans la région USA Est (Virginie du Nord), l'ARN ressemble à ce qui suit.

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

Pour en savoir plus sur les ARN, consultez Utilisation des Amazon Resource Names (ARN) dans Amazon RDS.

Pour créer un réplica en lecture chiffré dans une autre région AWS que l'instance de base de données source, vous pouvez utiliser la commande AWS CLI create-db-instance-read-replica de la région AWS destinataire. Les paramètres suivants sont utilisés pour créer un réplica en lecture chiffré dans une autre région AWS :

• --source-region — La région AWS dans laquelle le réplica en lecture chiffré est créé. Si source-region n'est pas spécifié, vous devez spécifier une valeur pre-signed-url. Une valeur pre-signed-url est une URL qui contient une demande signée via Signature Version 4 pour l'action CreateDBInstanceReadReplica qui est appelée dans la région AWS source à partir de laquelle le réplica en lecture est créé. Pour de plus amples informations sur pre-signed-url, veuillez consulter CreateDBInstanceReadReplica.

• --source-db-instance-identifier — L'identifiant d'instance de bases de données du réplica en lecture chiffré qui est créé. Cet identifiant doit être au format de nom ARN pour la région AWS source. La région AWS spécifiée dans source-db-instance-identifier doit correspondre à la région AWS spécifiée en tant que source-region.

• --db-instance-identifier — L'identifiant du réplica en lecture chiffré dans la région AWS de destination.

• --kms-key-id — L'identifiant de clé AWS KMS pour la clé à utiliser pour chiffrer le réplica en lecture dans la région AWS de destination.

Le code suivant crée un réplica en lecture dans la région us-west-2.

Exemple

Pour Linux, OS X ou Unix :

aws rds create-db-instance-read-replica \
    --db-instance-identifier DBInstanceIdentifier \
    --region us-west-2 \
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance          

Pour Windows :

aws rds create-db-instance-read-replica ^
    --db-instance-identifier DBInstanceIdentifier ^
    --region us-west-2 ^
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance
 

Le code suivant crée un réplica en lecture dans une autre région AWS que celle de l'instance de bases de données source. La région AWS où vous appelez la commande create-db-instance-read-replica correspond à la région AWS de destination du réplica en lecture chiffré.

Exemple

Pour Linux, OS X ou Unix :

aws rds create-db-instance-read-replica \
    --db-instance-identifier DBInstanceIdentifier \
    --region us-west-2 \
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance \
    --source-region us-east-1 \
    --kms-key-id my-us-east-1-key

Pour Windows :

aws rds create-db-instance-read-replica ^
    --db-instance-identifier DBInstanceIdentifier ^
    --region us-west-2 ^
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance ^
    --source-region us-east-1 ^	
    --kms-key-id my-us-east-1-key
 

API RDS

Pour créer un réplica en lecture à partir d'une instance de base de données MySQL, MariaDB ou PostgreSQL source dans une autre région AWS, vous pouvez appeler la fonction d'API Amazon RDS CreateDBInstanceReadReplica. Dans ce cas, vous appelez CreateDBInstanceReadReplica à partir de la région AWS où vous voulez placer le réplica en lecture et vous spécifiez l'Amazon Resource Name (ARN) pour l'instance de base de données source. Un ARN identifie de façon unique une ressource créée dans Amazon Web Services.

Pour créer un réplica en lecture chiffré dans une autre région AWS que celle de l'instance de base de données source, vous pouvez utiliser l'action d'API Amazon RDS CreateDBInstanceReadReplica de la région AWS destinataire. Pour créer un réplica en lecture chiffre dans une autre région AWS, vous devez spécifier une valeur pour PreSignedURL. PreSignedURL doit contenir une demande pour l'action CreateDBInstanceReadReplica à appeler dans la région AWS source dans laquelle le réplica en lecture est créé. Pour en savoir plus sur PreSignedUrl, consultez CreateDBInstanceReadReplica.

Par exemple, si votre instance de bases de données se trouve dans la région USA Est (Virginie du Nord), l'ARN ressemble à ce qui suit.

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

Pour en savoir plus sur les ARN, consultez Utilisation des Amazon Resource Names (ARN) dans Amazon RDS.

Exemple

https://us-west-2.rds.amazonaws.com/
    ?Action=CreateDBInstanceReadReplica
    &KmsKeyId=my-us-east-1-key
    &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F
         %253FAction%253D CreateDBInstanceReadReplica
         %2526DestinationRegion%253Dus-east-1
         %2526KmsKeyId%253Dmy-us-east-1-key
         %2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%1234567890
12%25253Adb%25253Amy-mysql-instance
         %2526SignatureMethod%253DHmacSHA256
         %2526SignatureVersion%253D4%2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Ainstance%25253Amysql-instance1-instance-20161115
         %2526Version%253D2014-10-31
         %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256
         %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request
         %2526X-Amz-Date%253D20161117T215409Z
         %2526X-Amz-Expires%253D3600
         %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date
         %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613
    &DBInstanceIdentifier=myreadreplica
    &SourceDBInstanceIdentifier=arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance
    &Version=2012-01-15						
    &SignatureVersion=2
    &SignatureMethod=HmacSHA256
    &Timestamp=2012-01-20T22%3A06%3A23.624Z
    &AWSAccessKeyId=<AWS Access Key ID>
    &Signature=<Signature>

Considérations liées à la réplication entre régions

Toutes les considérations liées à la réplication au sein d'une région AWS s'appliquent à la réplication entre régions. Les considérations supplémentaires suivantes s'appliquent lors d'une réplication entre régions :

• Vous pouvez répliquer entre des régions seulement lorsque vous utilisez des instances de bases de données Amazon RDS de MariaDB, PostgreSQL (versions 9.4.7, 9.5.2 et ultérieures), ou MySQL version 5.6 et ultérieure.

• Une instance de bases de données source peut avoir des réplicas en lecture entre régions dans plusieurs régions.

• Vous ne pouvez créer un réplica en lecture entre régions Amazon RDS qu'à partir d'une instance de base de données Amazon RDS qui n'est pas un réplica en lecture d'une autre instance de bases de données Amazon RDS.

• Vous ne pouvez pas configurer un canal de réplication à l'intérieur ou à l'extérieur de la région AWS GovCloud (US-West).

• Vous pouvez vous attendre à un degré supérieur de latence pour tout réplica en lecture figurant dans une autre région AWS que celle de l'instance source. Cette latence vient des canaux de réseau plus longs entre les centres de données régionaux.

• Au sein d'une même région AWS, tous les réplicas en lecture entre régions créés à partir de la même instance de bases de données source doivent figurer dans le même Amazon VPC ou être en dehors d'un VPC. Pour ces réplicas en lecture entre régions, toutes les commandes de création de réplica en lecture qui spécifient le paramètre --db-subnet-group-name doivent spécifier un groupe de sous-réseaux DB du même VPC.

• Vous pouvez également créer un réplica en lecture inter-région dans un VPC depuis une instance de base de données source qui se trouve dans un VPC dans une autre région. Vous pouvez également créer un réplica en lecture inter-région dans un VPC à partir d'une instance de base de données source qui ne figure pas dans un VPC. Vous pouvez également créer un réplica en lecture entre régions qui ne figure pas dans un VPC à partir d'une instance de bases de données source qui figure dans un VPC.

• En raison de la limite du nombre d'entrées de liste de contrôle d'accès (ACL) pour un VPC, nous ne pouvons pas garantir plus de cinq instances de réplica en lecture inter-régions.

Coûts de la réplication entre régions

Les données transférées pour la réplication entre régions génèrent des frais de transfert de données Amazon RDS. Ces actions de réplication entre régions génèrent des frais pour les données transférées hors de la région AWS source :

• Lorsque vous créez un réplica en lecture, Amazon RDS prend un instantané de l'instance source et transfère cet instantané vers la région du réplica en lecture.

• Pour chaque modification des données effectuée dans les bases de données sources, Amazon RDS transfère les données de la région AWS source vers la région du réplica en lecture.

Pour plus d'informations sur la tarification du transfert des données, consultez la Tarification Amazon RDS.

Pour les instances MySQL et MariaDB, vous pouvez réduire les coûts de transfert de données en réduisant le nombre de réplicas en lecture entre régions que vous créez. Par exemple, supposons si vous possédiez une instance de bases de données source dans une région AWS et que vous souhaitiez disposer de trois réplicas en lecture dans une autre région AWS. Dans ce cas, vous créez uniquement l'un des réplicas en lecture à partir de l'instance de bases de données source. Ensuite, vous créez les deux autres réplicas à partir du premier réplica en lecture plutôt qu'à partir de l'instance de bases de données source.

Par exemple, si vous avez source-instance-1 dans une région AWS, vous pouvez procéder comme suit :

• Créez read-replica-1 dans la nouvelle région AWS en spécifiant source-instance-1 comme source.

• Créez read-replica-2 à partir de read-replica-1.

• Créez read-replica-3 à partir de read-replica-1.

Dans cet exemple, seules les données transférées de source-instance-1 vers read-replica-1 vous sont facturées. Les données transférées de read-replica-1 vers les deux autres réplicas ne vous sont pas facturées, car ils figurent tous dans la même région AWS. Si vous créez les trois réplicas directement à partir de source-instance-1, les transferts de données vers les trois réplicas vous sont facturés.

Processus de réplication entre régions au sein d'Amazon RDS

Amazon RDS utilise le processus ci-dessous pour créer un réplica en lecture entre régions. Selon les régions impliquées et le volume de données figurant dans les bases de données, ce processus peut durer des heures. Vous pouvez utiliser ces informations pour déterminer l'avancement du processus lorsque vous créez un réplica en lecture entre régions :

1. Amazon RDS commence par configurer l'instance DB source comme source de réplication et définit le statut sur modifying (modification).

2. Amazon RDS commence à configurer le réplica en lecture spécifié dans la région AWS destinataire et définit le statut sur creating (création).

3. Amazon RDS crée un instantané de base de données automatisé de l'instance de bases de données source dans la région AWS source. Le format du nom de l'instantané de base de données est : rds:<InstanceID>-<timestamp>, où <InstanceID> est l'identifiant de l'instance source, et <timestamp> est la date et l'heure du début de la copie. Par exemple, rds:mysourceinstance-2013-11-14-09-24 a été créé à partir de l'instance mysourceinstance le 2013-11-14-09-24. Pendant la création de l'instantané de base de données automatique, le statut de l'instance de base de données source reste modifying (modification), le statut du réplica en lecture reste creating (création) et le statut de l'instantané de base de données est creating (création). La colonne d'avancement de la page de l'instantané de base de données dans la console indique le niveau d'avancement de la création de l'instantané de base de données. Une fois l'instantané de base de données terminé, le statut de l'instantané de base de données et celui de l'instance de base de données source sont définis sur available (disponible).

4. Amazon RDS commence une copie de l'instantané entre régions pour le transfert de données initial. La copie de l'instantané est répertoriée en tant qu'instantané automatisé dans la région AWS destinataire avec un statut creating (création). Elle porte le même nom que l'instantané de base de données source. La colonne d'avancement de l'affichage de l'instantané de base de données indique le niveau d'avancement de la copie. Une fois la copie terminée, le statut de la copie de l'instantané de base de données est défini sur available (disponible).

5. Amazon RDS utilise alors l'instantané de base de données copié pour le chargement initial des données sur le réplica en lecture. Au cours de cette phase, le réplica en lecture figure dans la liste des instances de bases de données de la destination, avec un statut égal à creating (création). Une fois le chargement terminé, le statut du réplica en lecture est défini sur available (disponible) et la copie de l'instantané de base de données est supprimée.

6. Lorsque le réplica en lecture atteint le statut disponible, Amazon RDS commence par répliquer les modifications apportées à l'instance source depuis le début de l'opération de création du réplica en lecture. Durant cette phase, la durée du retard de réplication pour le réplica en lecture est supérieure à 0.

   Pour de plus amples informations sur la durée du retard de réplication, veuillez consulter Supervision de la réplication en lecture.

Exemples de réplication entre régions

Exemple Création d'un réplica en lecture entre régions en dehors de tout VPC

L'exemple suivant illustre la création d'un réplica en lecture dans la région us-west-2 à partir d'une instance de bases de données source dans la région us-east-1. Ce réplica en lecture est créé en dehors de tout VPC :

Pour Linux, OS X ou Unix :

aws rds create-db-instance-read-replica \
    --db-instance-identifier SimCoProd01Replica01 \
    --region us-west-2
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01 

Pour Windows :

aws rds create-db-instance-read-replica ^
    --db-instance-identifier SimCoProd01Replica01 ^
    --region us-west-2
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01 

Exemple Créer un réplica en lecture entre régions dans un VPC

Cet exemple illustre la création d'un réplica en lecture dans la région us-west-2 à partir d'une instance de bases de données source dans la région us-east-1. Le réplica en lecture est créé dans le VPC associé au groupe de sous-réseaux DB spécifié :

Pour Linux, OS X ou Unix :

aws rds create-db-instance-read-replica \
    --db-instance-identifier SimCoProd01Replica01 \
    --region us-west-2
    --db-subnet-group-name my-us-west-2-subnet 
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01 

Pour Windows :

aws rds create-db-instance-read-replica ^
    --db-instance-identifier SimCoProd01Replica01 ^
    --region us-west-2
    --db-subnet-group-name my-us-west-2-subnet 
    --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01 

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 details 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 AWS CLI describe-db-instances ou de l'action d'API Amazon RDS DescribeDBInstances.

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

• replicating (réplication)—Le réplica en lecture réplique correctement.

• 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é)—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 bases de données source et tous les réplicas en lecture. Amazon RDS procède ainsi afin d'éviter des besoins en stockage accrus sur l'instance de base de données source et de longues durées 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) (MySQL ou MariaDB 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 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 SLAVE STATUS. Pour PostgreSQL, la métrique ReplicaLag contient la valeur de SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS slave_lag.

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.

Lorsque la métrique ReplicaLag atteint 0, le réplica a rattrapé l'instance de bases de données source. 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.

PostgreSQL (versions 9.4.7, 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 avec Amazon CloudWatch.