Vous pouvez également configurer la page de FAQ pour chaque moteur de base de données Amazon RDS pour les questions spécifiques à un moteur en particulier.

MySQL | MariaDB | Oracle | PostgreSQL | SQL Server

Pour voir les questions habituelles concernant Amazon Aurora, consultez la FAQ Amazon Aurora.

Découvrez gratuitement AWS

Créer un compte gratuit

L'offre gratuite d'AWS inclut 750 heures d'exécution d'une instance DB Micro chaque mois durant un an, 20 Go de stockage et 20 Go de sauvegardes avec Amazon Relational Database Service (RDS).

Voir les détails relatifs au niveau gratuit d'AWS »


Q : Qu'est-ce qu'Amazon RDS ?

Amazon Relational Database Service (Amazon RDS) est un service géré qui facilite l'installation, l'exploitation et le dimensionnement d'une base de données relationnelle dans le cloud. Ce service fournit une capacité économique et redimensionnable, tout en gérant les longues tâches d'administration de base de données, vous pouvez ainsi vous consacrer à vos applications et à votre activité.

Amazon RDS vous donne accès aux capacités d'une base de données classique MySQL, MariaDB, Oracle, SQL Server ou PostgreSQL. Ceci signifie que le code, les applications et les outils que vous utilisez déjà aujourd'hui avec vos bases de données existantes devraient fonctionner de manière transparente avec Amazon RDS. Amazon RDS peut automatiquement sauvegarder votre base de données et faire en sorte que le logiciel de votre base de données reste à jour avec la dernière version. Vous profitez de la flexibilité de pouvoir dimensionner facilement les ressources de calcul ou les capacités de stockage associées à votre instance de base de données relationnelle. En outre, Amazon RDS facilite l'utilisation des réplications pour améliorer la disponibilité des bases de données et la durabilité des données ou dimensionner au-delà des limites de capacité d'une instance de base de données unique, pour les charges de travail de base de données à lecture importante. A l'instar de tous les services AWS, il n'y a pas d'investissement initial à réaliser et vous ne payez que les ressources que vous utilisez.

Q : Quels sont les moteurs de base de données relationnelle pris en charge par Amazon RDS ?

Amazon RDS prend en charge les moteurs de base de données Amazon Aurora, MySQL, MariaDB, Oracle, SQL Server et PostgreSQL.

Q : Quelles opérations le service Amazon RDS effectue-t-il à ma place ?

Amazon RDS gère le travail qu'implique la configuration d'une base de données relationnelle, de la mise en service de la capacité d'infrastructure souhaitée à l'installation du logiciel de base de données. Une fois que votre base de données est opérationnelle, Amazon RDS automatise les tâches administratives courantes, comme les sauvegardes et le correctif du logiciel qui fait fonctionner votre base de données. En cas d'éventuels déploiements Multi-AZ, Amazon RDS gère également la réplication synchrone des données sur les zones de disponibilité par le biais du basculement automatique.

Étant donné qu'Amazon RDS fournit un accès natif aux bases de données, vous interagissez avec le logiciel de la base de données relationnelle comme d'habitude. Cela signifie que vous êtes toujours responsable de la gestion des paramètres de la base de données spécifiques à votre application. Vous devrez concevoir le schéma relationnel qui convient le mieux à votre cas d'application et vous serez responsable de tout réglage de performance visant à optimiser votre base de données pour le flux de travail de votre application.

Q : Quand vaut-il mieux utiliser Amazon RDS plutôt que les AMI de base de données relationnelle Amazon EC2 ?

Amazon Web Services propose aux développeurs plusieurs solutions de bases de données. Amazon RDS permet de gérer une base de données relationnelle riche en fonctionnalités, tout en allégeant son administration. L'utilisation de l'une de nos nombreuses AMI de base de données relationnelle sur Amazon EC2 vous permet de gérer votre propre base de données relationnelle dans le cloud. D'importantes différences existent et, selon votre utilisation, une alternative peut s'avérer plus adaptée que les autres. Consultez la page Les bases de données dans le cloud avec AWS pour déterminer la solution la plus appropriée à votre cas d'application.

Q : Comment démarrer avec Amazon RDS ?

Pour vous inscrire à Amazon RDS, vous devez posséder un compte Amazon Web Services. Créez un compte si vous n'en avez pas encore. Après vous être inscrit, consultez la Documentation Amazon RDS , qui inclut notre manuel de mise en route Getting Started Guide.

Amazon RDS fait partie intégrante de l'offre gratuite AWS de façon à ce que les nouveaux clients AWS puissent commencer à utiliser gratuitement un service de base de données géré dans le cloud.


Q : Qu'est-ce qu'une instance de base de données (instance DB) ?

Vous pouvez considérer une instance DB comme un environnement de base de données dans le cloud avec les ressources de calcul et de stockage que vous spécifiez. Vous pouvez créer et supprimer des instances DB, définir/affiner des attributs d'infrastructure de votre/vos instances DB et contrôler l'accès et la sécurité via AWS Management Console, les API Amazon RDS et l'interface de ligne de commande AWS. Vous pouvez exécuter une ou plusieurs instances DB, et chacune de ces instances peut prendre en charge une ou plusieurs bases de données, ou différents schémas de bases de données, selon le type de moteur.  

Q : Comment créer une instance DB ?

Pour créer des instances DB, il suffit d'utiliser AWS Management Console, les API Amazon RDS ou l'interface de ligne de commande AWS. Pour lancer une instance DB à l'aide d'AWS Management Console, cliquez sur « RDS », puis sur le bouton Launch DB Instance dans l'onglet Instances. De là, vous pouvez préciser les paramètres de votre instance DB, notamment le moteur et la version de la DB, le modèle de licence, le type d'instance, le type et la quantité de stockage et les informations d'identification de l'utilisateur principal.

Vous pouvez également modifier la politique de rétention de sauvegarde, le créneau de sauvegarde préféré et le créneau de maintenance planifié de votre instance DB. Vous pouvez également créer votre instance DB à l'aide de l'API CreateDBInstance ou de la commande create-db-instance.

Q : Comment puis-je accéder à mon instance DB en cours d'exécution ?

Une fois que votre instance DB est disponible, vous pouvez récupérer son point de terminaison via la description d'instance DB dans AWS Management Console, l'API DescribeDBInstances ou la commande describe-db-instances. En utilisant ce point de terminaison, vous pouvez construire la chaîne de connexion requise pour vous connecter directement à votre instance DB en utilisant votre outil de base de données ou langage de programmation préféré. Afin d'autoriser les demandes de réseau vers votre instance DB en cours d'exécution, vous devez autoriser l'accès. Pour une explication détaillée sur la construction de votre chaîne de connexion et sur le démarrage, consultez notre manuel Getting Started Guide.

Q : Combien d'instances DB puis-je exécuter avec Amazon RDS ?

Par défaut, les clients sont autorisés à avoir jusqu'à 40 instances DB Amazon RDS au total. Sur ces 40 instances, jusqu'à 10 peuvent être des instances DB Oracle ou SQL Server exécutées sous le modèle « License Included » (licence incluse). En revanche, les 40 instances peuvent être utilisées pour Amazon Aurora, MySQL, MariaDB, PostgreSQL et Oracle ou SQL Server sous le modèle « BYOL » (licence à fournir). Si votre demande nécessite plus de vingt instances DB, vous pouvez demander des instances DB supplémentaires via ce formulaire de demande.

Q : Combien de bases de données ou de schémas puis-je exécuter au sein d'une instance DB ?

  • RDS pour Amazon Aurora : pas de limite imposée par le logiciel
  • RDS pour MySQL : Pas de limite imposée par le logiciel
  • RDS pour MariaDB : pas de limite imposée par le logiciel
  • RDS pour Oracle : 1 base de données par instance ; pas de limite imposée par le logiciel quant au nombre de schémas par base de données
  • RDS pour SQL Server : 30 bases de données par instance
  • RDS pour PostgreSQL : Pas de limite imposée par le logiciel

Q : Comment importer des données dans une instance DB Amazon RDS ?

Il existe de nombreuses méthodes très simples pour importer des données dans Amazon RDS, notamment les utilitaires mysqldump ou mysqlimport pour MySQL, Data Pump, import/export ou SQL Loader pour Oracle, l'assistant Import/Export, les fichiers de sauvegarde complète (fichiers .bak) ou Bulk Copy Program (BCP) pour SQL Server, ou encore pg_dump pour PostgreSQL. Pour en savoir plus sur l'importation et l'exportation des données, consultez les manuels Data Import Guide for MySQL, Data Import Guide for Oracle, Data Import Guide for SQL Server ou Data Import Guide for PostgreSQL.

Par ailleurs, AWS Database Migration Service peut vous aider à migrer des bases de données vers AWS très simplement et en toute sécurité.

Q : Qu'est-ce qu'une fenêtre de maintenance ? Mon instance DB sera-t-elle disponible pendant les événements de maintenance ?

La fenêtre de maintenance d'Amazon RDS vous offre la possibilité de contrôler le moment auquel les modifications d'instance DB (telles que le dimensionnement de la classe d'instance DB) et la correction de logiciel ont lieu, dans le cas où celles-ci seraient demandées ou nécessaires. Si un événement de maintenance est planifié pour une semaine donnée, il sera déclenché et effectué à un moment donné au cours de la fenêtre de maintenance que vous identifiez. Les fenêtres de maintenance durent 30 minutes.

Amazon RDS doit déconnecter votre instance DB uniquement durant les opérations de calcul de dimensionnement (qui ne prennent généralement que quelques minutes en tout) ou la correction de logiciel requise. La correction requise est planifiée automatiquement et uniquement pour les correctifs en rapport à la sécurité et à la durabilité. Ce type de correction a lieu peu fréquemment (en général une fois à quelques mois d'intervalle) et devrait rarement nécessiter plus d'une fraction de votre fenêtre de maintenance. Si vous ne spécifiez pas un fenêtre de maintenance hebdomadaire privilégiée lors de la création de votre instance DB, une valeur par défaut de 30 minutes est assignée. Si vous souhaitez modifier la planification de la maintenance, vous pouvez le faire en modifiant votre instance DB via AWS Management Console, l'API ModifyDBInstance ou la commande modify-db-instance. Si vous le souhaitez, vous pouvez attribuer un créneau de maintenance préféré différent à chacune de vos instances DB.

L'exécution de votre instance DB comme déploiement multi-AZ peut réduire davantage l'impact d'un événement de maintenance. Pour plus d'informations sur les opérations de maintenance, consultez le manuel Amazon RDS User Guide.

Q : Que faire si mes requêtes semblent s'exécuter lentement ?

Pour les bases de données de production, nous vous encourageons à activer la surveillance améliorée qui permet d'accéder à plus de 50 métriques, comme le CPU, la mémoire, le système de fichiers et les entrées/sorties de disque. Vous pouvez activer ces fonctionnalités par instance et choisir la granularité (jusqu'à 1 seconde). Les niveaux élevés d'utilisation de CPU peuvent réduire les performances des requêtes et dans ce cas, vous devrez peut-être envisager le dimensionnement de votre classe d'instance DB. Pour en savoir plus sur la surveillance de votre instance DB, consultez le manuel Amazon RDS User Guide.

Si vous utilisez RDS pour MySQL ou MariaDB, vous pouvez accéder aux journaux de requêtes lentes de MySQL pour votre base de données, afin de déterminer si des requêtes SQL s'exécutent lentement et, le cas échéant, les caractéristiques de performance de chacune d'entre elles. Vous pouvez définir le paramètre DB slow_query_log et interrogez la table mysql.slow_log pour vérifier les requêtes SQL qui s'exécutent lentement. Pour en savoir plus, consultez le manuel Amazon RDS User Guide.

Si vous utilisez RDS pour Oracle, vous pouvez utiliser les données du fichier trace Oracle pour identifier les requêtes lentes. Pour plus d'informations sur l'accès aux données du fichier trace, veuillez vous référer au manuel Amazon RDS User Guide.

Si vous utilisez RDS pour SQL Server, vous pouvez exploiter les fichiers trace SQL Server côté client pour identifier les requêtes lentes. Pour plus d'informations sur l'accès aux données des fichiers de trace, reportez-vous au manuel Amazon RDS User Guide.


Q : Quelles sont les versions du moteur de base de données relationnelle prises en charge par Amazon RDS ?

Consultez le manuel Amazon Aurora User Guide pour en savoir plus sur les versions de base de données Amazon Aurora.

Q : Comment Amazon RDS fait-il la distinction entre les versions de moteur DB « majeures » et « mineures » ?

Consultez la page des FAQ pour chaque moteur de base de données Amazon RDS afin d'en savoir plus sur la numérotation des versions.

Q : Amazon RDS donne-t-il des consignes concernant la prise en charge des nouveaux moteurs DB ?

A mesure que le temps passe, Amazon RDS inclut la prise en charge des versions de moteur de base de données majeures et mineures. Le nombre de nouvelles versions prises en charge dans une année donnée variera en fonction de la fréquence et du contenu des parutions et des correctifs diffusés par le fournisseur du moteur ou par l'organisation en charge du développement, et en fonction du résultat d'un examen approfondi de ces parutions et correctifs par notre équipe d'ingénierie en bases de données. Toutefois, en règle générale, nous souhaitons prendre en charge de nouvelles versions de moteur dans les 5 mois après leur disponibilité générale.

Q : Comment spécifier la version du moteur DB prise en charge que j'aimerais que mon instance DB exécute ?

Vous pouvez spécifier n'importe quelle version (majeure ou mineure) actuellement prise en charge lors de la création d'une nouvelle instance DB via l'opération Launch DB Instance dans l'AWS Management Console ou l'API CreateDBInstance. Veuillez noter que toutes les versions de moteur de base de données ne sont pas disponibles dans toutes les régions AWS.

Q : Comment puis-je contrôler si et quand la version du moteur de mon instance DB est mise à niveau vers les nouvelles versions prises en charge ?

Amazon RDS s'efforce de faire en sorte que votre instance de base de données reste à jour en vous fournissant les nouvelles versions des moteurs de base de données pris en charge. Après la publication d'une nouvelle version d'un moteur de base de données par le fournisseur ou par l'organisation en charge du développement, celle-ci doit être testée minutieusement par notre équipe d'ingénieurs spécialisés en bases de données avant d'être mise à disposition dans Amazon RDS.

Nous vous recommandons de veiller à ce que votre instance de base de données soit toujours mise à niveau vers la version mineure la plus récente, car celle-ci inclura les dernières corrections liées à la sécurité et aux fonctionnalités. Contrairement aux mises à niveau des versions majeures, Les mises à niveau des versions mineures comprennent uniquement les changements rétrocompatibles avec les versions mineures antérieures (de la même version majeure) du moteur de base de données.

Si une nouvelle version mineure ne contient pas les corrections qui pourraient être utiles aux clients RDS, nous pouvons choisir de ne pas la mettre à disposition dans RDS. Dès qu'une nouvelle version mineure est disponible dans RDS, Nous ferons en sorte qu'elle soit la version mineure privilégiée pour les nouvelles instances DB.

Pour mettre à niveau manuellement une instance de base de données vers une version de moteur prise en charge, utilisez la commande Modify DB Instance sur l'AWS Management Console ou l'API ModifyDBInstance et réglez le paramètre DB Engine Version sur la version souhaitée. La mise à niveau sera effectuée par défaut ou lors de votre prochaine fenêtre de maintenance. Vous pouvez également choisir d'effectuer la mise à niveau immédiatement en cochant l'option Apply Immediately dans l'API de la console.

Si nous déterminons qu'une nouvelle version de moteur mineure contient des corrections de bugs importantes par rapport à une ancienne version mineure, nous programmerons des mises à niveau automatiques pour les instances DB pour lesquelles le réglage Auto Minor Version Upgrade indique « Yes ». L'exécution de ces mises à niveau sera prévue pour les fenêtres de maintenance indiquées par le client.

Nous annoncerons les mises à niveau programmées sur le forum Amazon RDS et enverrons par e-mail des notifications à nos clients au moins 30 jours avant l'exécution. Nous les planifions afin de vous puissiez vous y adapter, car une période d'indisponibilité est nécessaire pour mettre à niveau une version de moteur de base de données, même en cas d'instances multi-AZ. Si vous souhaitez stopper les mise à niveau de version mineure automatiques, vous pouvez le faire en définissant le réglage Auto Minor Version Upgrade sur « No ».

Dans le cas de RDS pour Oracle et RDS pour SQL Server, si la mise à niveau vers la prochaine version mineure nécessite de changer d'édition, il se peut que nous ne puissions pas programmer de mises à niveau automatiques, même si vous avez activé le réglage Auto Minor Version Upgrade. Dans une telle situation, nous déterminons au cas par cas si les mises à niveau doivent être programmées.

Etant donné que les mises à niveau de version majeure impliquent quelques risques de compatibilité, elles ne se produiront pas automatiquement et doivent être lancées par vous (sauf en cas de dépréciation de version majeure, voir ci-dessous).

Pour plus d'informations sur la mise à niveau d'une instance DB vers une nouvelle version du moteur DB, consultez le manuel Amazon RDS User Guide.

Q : Puis-tester mon instance DB avec une nouvelle version avant la mise à niveau ?

Oui. Vous pouvez le faire en créant un snapshot DB de votre instance DB existante, en restaurant depuis le snapshot pour créer une nouvelle instance DB, puis en lançant une mise à niveau de version pour la nouvelle instance DB. Vous pouvez expérimenter ensuite en toute sécurité sur le clone mis à niveau de votre instance DB avant de décider si vous voulez mettre à niveau votre instance DB d'origine.

Pour en savoir plus sur la restauration d'un snapshot DB, consultez le manuel Amazon RDS User Guide.

Q : Amazon RDS donne-t-il des consignes concernant la dépréciation des versions de moteur de base de données actuellement prises en charge ?

  • Nous avons l'intention de prendre en charge des versions MySQL majeures (ex. : MySQL 5.6, PostgreSQL 9.6) pendant au moins 3 ans après leur prise en charge initiale par Amazon RDS.
  • Nous avons l'intention de prendre en charge des versions MySQL mineures (ex. : MySQL 5.6.21, PostgreSQL 9.6.1) pendant au moins 1 an après leur prise en charge initiale par Amazon RDS.

Nous arrêterons de mettre à jour les versions de moteur majeures et mineures de façon périodique. Pour les versions majeures, on envisage généralement la dépréciation lorsque la version est passée au support étendu ou lorsqu'elle ne reçoit plus de corrections logicielles ou de mises à jour de sécurité. Pour les versions mineures, on envisage la dépréciation lorsqu'elles rencontrent des bugs ou des problèmes de sécurité importants, qui ont été résolus dans une version mineure ultérieure.

Alors que nous nous efforçons de satisfaire à ces directives, nous sommes susceptibles, dans certains cas, de rendre obsolètes des versions mineures ou majeures spécifiques plus tôt que prévu, notamment en cas de problèmes de sécurité. Dans l'éventualité peu probable où cela se produit, Amazon RDS mettra automatiquement votre moteur de base de données à niveau pour résoudre ce problème. Des conditions particulières peuvent exiger des calendriers différents, selon le problème à résoudre.

Q : Que se passe-t-il si une version de moteur DB RDS devient obsolète ?

Si une version mineure d'un moteur de base de données devient obsolète dans Amazon RDS, nous programmons des mises à niveau automatiques pour les instances pour lesquelles le réglage Auto Minor Version Upgrade doit être exécuté au moins 30 jours après l'annonce de la dépréciation sur le forum et l'envoi de notifications aux clients par e-mail. Nous désactiverons également la création de nouvelles instances avec cette version. Suivant un délai de grâce minimum de trois mois après l'annonce, nous programmerons la mise à niveau automatique de toutes les instances exécutant toujours la version mineure obsolète vers une version mineure prise en charge pour qu'elle ait lieu au cours de la fenêtre de maintenance indiquée.

Si une version majeure d'un moteur de base de données devient obsolète dans Amazon RDS, nous accorderons un délai de grâce minimum de six mois suivant l'annonce de la dépréciation avant la fin duquel vous devrez avoir mis à niveau la version concernée vers une version majeure prise en charge. Au terme de ce délai de grâce, une mise à niveau automatique sera appliquée à toutes les instances exécutant toujours la version obsolète lors de leur fenêtre de maintenance programmée.

Lorsqu'une version de moteur de base de données majeure ou mineure n'est plus prise en charge dans Amazon RDS, toute instance DB restaurée à partir d'un snapshot DB créé avec la version non prise en charge sera immédiatement et automatiquement mise à niveau vers une version actuellement prise en charge.


Q : Comment l'utilisation d'Amazon RDS me sera-t-elle facturée ?

Vous ne payez que ce que vous utilisez et il n'y a pas de frais minimum ou d'installation. Vous êtes facturé sur la base des éléments suivants :

  • Heures d'instance DB – selon la classe (par ex. db.t2.micro, db.m4.large) de l'instance DB consommée. Les heures d'instance DB partielles consommées sont facturées en tant qu'heures entières.
  • Stockage (par Go par mois) – capacité de stockage que vous avez réservée à votre instance DB. Si vous dimensionnez votre capacité de stockage au cours du mois, votre facture sera ajustée au prorata.
  • Demandes d'I/O par mois – nombre total de demandes d'E/S de stockage dont vous disposez (pour le stockage de type magnétique Amazon RDS et Amazon Aurora uniquement)
  • IOPS provisionnés par mois – taux d'IOPS provisionnés, indépendamment des IOPS consommés (pour le stockage IOPS provisionnés [SSD] Amazon RDS uniquement)
  • Stockage de sauvegarde – le stockage de sauvegarde est le stockage associé à vos sauvegardes de base de données automatisées et à tout instantané de base de données généré par le client. L'allongement de votre période de rétention de sauvegarde ou la création d'instantanés de base de données supplémentaires augmente le stockage de sauvegarde consommé par votre base de données.
  • Transfert de données – transfert de données sur Internet entrant et sortant de votre instance DB.

Pour des informations sur les tarifs Amazon RDS, consultez la section des tarifs sur la page des produits d'Amazon RDS.

Q : Quelles sont les dates de début et de fin de facturation de mes instances DB Amazon RDS ?

La facturation commence dès que l'instance DB est disponible. La facturation continue jusqu'à ce que l'instance DB se termine, ce qui se produira au moment de la suppression ou dans le cas d'une défaillance d'instance.

Q : Qu'est-ce qui définit les heures d'instance DB d'Amazon RDS facturables ?

Les heures d'instance DB sont facturées pour chaque heure d'exécution de votre instance DB en état de disponibilité. Si vous ne souhaitez plus être facturé pour votre instance DB, vous devez l'arrêter ou la supprimer afin que des heures d'instance supplémentaires ne vous soient pas facturées. Les heures d'instance DB partielles consommées sont facturées en tant qu'heures entières.

Q : Comment l'instance de base de données arrêtée sera-t-elle facturée ?

Pendant l'arrêt de votre instance de base de données, vous êtes facturé pour le stockage provisionné (y compris les IOPS provisionnés) et le stockage de sauvegardes (y compris les clichés manuels et les sauvegardes automatiques avec fenêtre de conservation spécifiée), mais pas pour les heures d'instance de base de données.

Q : Pourquoi le stockage de sauvegardes supplémentaire coûte-t-il plus cher que le stockage d'instances DB supplémentaire alloué ?

Le stockage mis en service sur votre instance DB pour vos données principales est situé dans une seule zone de disponibilité. Lorsque votre base de données est sauvegardée, les données sauvegardées (y compris les journaux de transactions) sont répliquées de manière géo-redondante sur plusieurs zones de disponibilité pour fournir des niveaux encore plus élevés de durabilité des données. Le prix du stockage de sauvegarde au-delà de votre attribution gratuite reflète cette réplication supplémentaire, qui a lieu pour maximiser la durabilité de vos sauvegardes vitales.

Q : Comment les déploiements multi-AZ d'instances DB me seront-ils facturés ?

Si vous spécifiez que votre instance DB doit être un déploiement multi-AZ, vous serez facturé en fonction du prix multi-AZ posté sur la page des tarifs d'Amazon RDS. La facturation multi-AZ est basée sur :

  • Heures d'instance DB multi-AZ – selon la classe (par ex. db.t2.micro, db.m4.large) de l'instance DB consommée. Comme pour les déploiements standards dans une seule zone de disponibilité, les heures d'instance DB partielles consommées sont facturées en tant qu'heures entières. Si vous convertissez votre déploiement d'instance DB entre le mode standard et Multi-AZ dans une heure donnée, les deux tarifs s'appliqueront pour cette heure.
  • Stockage réservé (pour les instances DB Multi-AZ) – si vous convertissez votre déploiement d'instance DB entre le mode standard et Multi-AZ dans une heure donnée, le tarif de stockage le plus élevé s'appliquera pour cette heure.
  • Demandes I/O par mois – nombre total de demandes I/O de stockage que vous avez. Les déploiements Multi-AZ consomment un plus grand volume de demandes I/O que les déploiements d'instance DB standards, en fonction de votre ratio écriture/lecture de base de données. Écrire l'utilisation E/S associée aux mises à jour de base de données doublera, car Amazon RDS réplique de manière synchrone vos données vers l'instance DB de secours. L'utilisation en lecture E/S restera la même.
  • Stockage de sauvegarde – votre utilisation de stockage de sauvegarde ne changera pas, que votre instance DB soit un déploiement standard ou multi-AZ. Les sauvegardes seront simplement prises de votre base de données de secours, afin d'éviter la suspension I/O sur l'instance DB principale.
  • Transfert de données – le transfert de données durant la réplication des données entre vos bases de données principale et de secours ne vous est pas facturé. Le transfert de données sur Internet entrant et sortant de votre instance DB est facturé de la même façon qu'avec un déploiement standard.

Q : vos prix sont-ils toutes taxes comprises ?

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus.


Q : Quelles sont les caractéristiques du niveau gratuit d'AWS pour Amazon RDS ?

L'offre gratuite d'AWS pour Amazon RDS permet d'utiliser gratuitement les instances de base de données mono-AZ de type Micro exécutant MySQL, MariaDB, PostgreSQL, Oracle (modèle « Bring-Your-Own-License » (BYOL), licence à fournir) et SQL Server Express Edition. Ce niveau d'offre gratuite est limité à 750 heures d'utilisation d'instances par mois. De plus, les clients bénéficient gratuitement de 20 Go de stockage de base de données à usage général (SSD) et de 20 Go de stockage de sauvegarde par mois.

Q : Pendant combien de temps pourrai-je disposer de l'offre Niveau gratuit d'AWS pour Amazon RDS ?

Les nouveaux comptes AWS bénéficient d'un an d'accès au niveau gratuit d'AWS. Pour en savoir plus, consultez la page FAQ sur le niveau gratuit d'AWS.

Q : Puis-je exécuter plusieurs instances DB dans le cadre de l'offre Niveau d'utilisation gratuit d'AWS pour Amazon RDS ?

Oui. Vous pouvez exécuter plusieurs instances DB mono-AZ de type Micro simultanément et remplir les conditions pour que leur utilisation soit comptabilisée dans le cadre du niveau gratuit d'AWS pour Amazon RDS. Toutefois, toute utilisation au-delà de ces 750 heures, sur l'ensemble des instances DB Amazon RDS de type Micro mono-AZ, et dans toutes les régions et tous les moteurs de base de données éligibles, sera facturée en fonction des tarifs standard d'Amazon RDS.

Par exemple : si vous exécutez deux instances DB mono-AZ de type Micro pendant 400 heures chacune au cours d'un même mois, vous accumulerez 800 heures d'utilisation d'instances, sur lesquelles 750 heures seront gratuites. Vous serez facturé pour les 50 heures restantes en fonction des tarifs standard d'Amazon RDS.

Q : Puis-je bénéficier de 750 heures d'utilisation pour chacune des instances DB Micro MySQL, MariaDB, PostgreSQL, Oracle et SQL Server dans le cadre du niveau gratuit d'AWS ?

Non. Un client bénéficiant du niveau gratuit d'AWS peut bénéficier de 750 heures d'utilisation gratuite au maximum sur l'ensemble des instances Micro exécutant MySQL, PostgreSQL, Oracle ou SQL Server Express Edition. Toute utilisation au-delà de ces 750 heures, sur l'ensemble des instances DB mono-AZ Amazon RDS de type Micro, et dans toutes les régions et tous les moteurs de base de données éligibles, sera facturée en fonction des tarifs standard d'Amazon RDS.

Q : L'offre Niveau gratuit d'AWS pour Amazon RDS est-elle disponible dans toutes les régions AWS ?

Le Niveau gratuit d'AWS pour Amazon RDS est disponible dans toutes les régions AWS, à l'exception de GovCloud (USA).

Q : Comment suis-je facturé si mon utilisation des heures d'instance dépasse l'offre du Niveau gratuit ?

Vous êtes facturé selon les tarifs standard d'Amazon RDS pour les heures d'instance dépassant celles offertes par le Niveau gratuit. Pour en savoir plus, consultez la page relative à la tarification d'Amazon RDS.


Q : Qu'est-ce qu'une instance réservée (IR) ?

Les instances réservées Amazon RDS vous permettent de réserver une instance DB pour une durée d'un ou trois ans. En retour, vous bénéficiez d'une remise conséquente sur les tarifs de l'instance DB par rapport à la tarification des instances à la demande. Il existe trois options de paiement pour les instances réservées : Aucuns frais initiaux, Frais initiaux partiels et Tous les frais initiaux. Celles-ci vous permettent de trouver le juste équilibre entre le montant initial payé et le tarif horaire effectif.  

Q : En quoi les instances réservées diffèrent-elles des instances DB à la demande ?

D'un point de vue fonctionnel, les instances DB réservées et celles à la demande sont exactement identiques. La seule différence est la manière dont elles vous sont facturées : avec les instances réservées, vous achetez une réservation d'un ou trois ans et bénéficiez, en retour, d'un tarif d'utilisation horaire moins élevé (par rapport aux instances de base de données la demande) pendant la durée de la période de réservation. A moins que vous n'achetiez des instances réservées dans une région, toutes les instances de base de données seront facturées aux tarifs horaires à la demande.

Q : Comment acheter et créer des instances réservées ?

Vous pouvez acheter une instance réservée dans la section « Reserved Instance » d'AWS Management Console pour Amazon RDS. Vous pouvez également utiliser l'API Amazon RDS ou l'interface de ligne de commande AWS pour afficher la liste des réservations disponibles à l'achat, puis acheter une réservation d'instance DB.

Lorsque vous avez acheté une réservation, l'utilisation d'une instance DB réservée est semblable à celle d'une instance DB à la demande. Lancez une instance DB en utilisant la même classe d'instance, le même moteur et la même région que ceux pour lesquels vous avez effectué la réservation. Tant que votre achat de réservation est actif, Amazon RDS appliquera un tarif horaire réduit à la nouvelle instance DB.

Q : Les instances réservées incluent-elles une réservation de capacité ?

Les instances réservées Amazon RDS sont achetées pour une région plutôt que pour une zone de disponibilité spécifique. Les instances réservées n'étant pas spécifiques à une zone de disponibilité, elles ne fournissent pas de réservations de capacité. Ainsi, même si la capacité est limitée dans une zone de disponibilité, les réservations peuvent toujours être achetées dans la région et la remise s'appliquera à l'utilisation correspondante dans une zone de disponibilité de cette région.

Q : Combien d'instances réservées puis-je acheter ?

Vous pouvez acheter jusqu'à 40 instances DB réservées. Si vous souhaitez exécuter plus de 40 instances DB, veuillez remplir le formulaire de demande d'instance DB d'Amazon RDS.

Q : Que faire si je souhaite convertir une instance de base de données existante en instance réservée ?

Il suffit d'acheter une réservation d'instance de base de données avec la même classe d'instance de base de données, le même moteur de base de données, la même option Multi-AZ et le même modèle de licence dans la même région que l'instance de base de données que vous exécutez actuellement et que vous aimeriez réserver. Lorsque la réservation est terminée, Amazon RDS appliquera automatiquement le nouveau coût d'utilisation horaire à votre instance DB existante.

Q : Si j'achète une instance réservée, quand commence la période de réservation ? Qu'arrive-t-il à mon instance DB lorsque la période se termine ?

Les changements de tarif associés à une instance réservée sont activés une fois que votre demande a été reçue, alors que l'autorisation de paiement est traitée. Vous pouvez suivre le statut de votre réservation sur la page d'activité du compte AWS ou en utilisant l'API DescribeReservedDBInstances ou la commande describe-reserved-db-instances. Si le paiement unique ne peut pas être autorisé avant la période de facturation suivante, le tarif réduit ne sera pas appliqué.

Lorsque votre période de réservation expire, votre instance réservée reviendra au tarif d'utilisation horaire à la demande pour votre classe et région d'instance DB.

Q : Comment contrôler les instances DB facturées au tarif des instances réservées ?

Les opérations de création, de modification et de suppression d'instances DB réalisées à l'aide d'Amazon RDS ne font pas la distinction entre les instances à la demande et les instances réservées. Lors du calcul de votre facture, notre système applique automatiquement votre/vos réservations, afin que toutes les instances DB éligibles soient facturées à un tarif horaire inférieur, conformément à la tarification des instances DB réservées.

Q : Si j'augmente ou diminue ma classe d'instance DB, qu'arrivera-t-il à ma réservation ?

Chaque réservation est associée aux attributs suivants : Moteur DB, Classe d'instance DB, Option de déploiement Multi-AZ, Modèle de licence et Région.

Une réservation pour un moteur DB et un modèle de licence éligible pour la taille flexible (MySQL, MariaDB, PostgreSQL, Amazon Aurora ou « Bring Your Own License » d'Oracle) s'appliquera automatiquement à une instance DB en cours d'exécution, quelle qu'en soit la taille, dans la même famille d'instances (par exemple, M4, T2 ou R3) pour le même moteur de base de données et la même région. En outre, la réservation s'appliquera également aux instances DB s'exécutant dans leurs options de déploiement soit mono-AZ, soit multi-AZ.

Par exemple, disons que vous avez acheté une réservation MySQL db.m4.2xlarge. Si vous décidez de dimensionner l'instance DB en cours d'exécution selon une réservation db.m4.4xlarge, le tarif décompté de cette instance réservée couvrira la moitié de l'utilisation de la plus grande instance DB.

Si vous exécutez un moteur DB ou un modèle de licence non éligible pour la taille flexible (Microsoft SQL Server ou « License Included » d'Oracle), chaque réservation ne peut s'appliquer qu'à une instance DB avec les mêmes attributs pour la période de réservation. Si vous décidez de modifier l'un des attributs de votre classe d'instance DB en cours avant la fin de la période de réservation, vos tarifs d'utilisation horaire pour cette instance DB repasseront aux tarifs horaires à la demande.

Pour en savoir plus sur la taille flexible, consultez le manuel de l'utilisateur Amazon RDS User Guide.

Q : Puis-je déplacer une instance réservée depuis une région ou une zone de disponibilité vers une autre ?

Chaque instance réservée est associée à une région spécifique, qui est fixée pendant la durée de la réservation et ne peut pas être modifiée. Toutefois, chaque réservation peut être utilisée dans n'importe laquelle des zones de disponibilité au sein de la région associée.

Q : Les instances réservées sont-elles disponibles pour des déploiements multi-AZ ?

Oui. Lorsque vous appelez l'API DescribeReservedDBInstancesOfferings ou la commande describe-reserved-db-instances-offerings, il vous suffit d'examiner les options Multi-AZ listées parmi les configurations d'instance DB disponibles à l'achat. Si vous voulez acheter une réservation pour une instance DB avec réplication synchrone sur plusieurs zones de disponibilité, spécifiez l'une de ces offres lors de votre appel PurchaseReservedDBInstancesOffering.

Q : Les instances réservées sont-elles disponibles pour des réplicas en lecture ?

Une réservation d'instance DB peut être appliquée à un réplica en lecture, à condition que la classe d'instance DB et la région soient les mêmes. Lors du calcul de votre facture, notre système applique automatiquement votre/vos réservations, afin que toutes les instances DB éligibles soient facturées à un tarif horaire inférieur, conformément à la tarification des instances DB réservées.

Q : Puis-je annuler une réservation ?

Non, vous ne pouvez pas annuler votre instance DB réservée, et le paiement initial (le cas échéant) n'est pas remboursable. Vous continuerez de payer chaque heure de la période définie pour votre instance DB réservée, quelle que soit son utilisation.

Q : Comment les options de paiement se répercutent-elles sur ma facture ?

Lorsque vous achetez une instance réservée avec l'option de paiement Tous les frais initiaux, vous réglez toute la durée de réservation de l'instance en un seul paiement initial. Vous avez aussi la possibilité de ne pas payer de frais initiaux, en choisissant l'option Aucuns frais initiaux. La valeur totale de l'instance réservée avec l'option de paiement Aucuns frais initiaux est répartie sur chaque heure de la durée de réservation. Vous serez donc facturé pour chaque heure, quelle que soit votre utilisation. L'option de paiement Frais initiaux partiels se situe à mi-chemin entre les options Tous les frais initiaux et Aucuns frais initiaux. Vous payez une faible somme initiale et êtes ensuite facturé selon un tarif horaire réduit pour chaque heure de réservation de l'instance, quelle que soit votre utilisation.


Q : Comment déterminer quelles classes d'instances DB et capacités de stockage initiales conviennent à mes besoins ?

Pour sélectionner votre classe d'instance DB et votre capacité de stockage initiales, vous devez évaluer les besoins de calcul, de mémoire et de stockage de votre application. Pour plus d'informations sur les classes d'instances DB disponibles, consultez le manuel Amazon RDS User Guide.

Q : Comment dimensionner les ressources de calcul et/ou les capacités de stockage associées à mon instance de base de données Amazon RDS ?

Vous pouvez dimensionner les ressources de calcul et les capacités de stockage allouées à votre instance DB à l'aide d'AWS Management Console (en sélectionnant l'instance DB souhaitée et en cliquant sur le bouton Modify), de l'API RDS ou de l'interface de ligne de commande AWS. Les ressources de mémoire et de CPU sont modifiées en changeant votre classe d'instance DB et le stockage disponible est changé lorsque vous modifiez votre attribution de stockage. Veuillez noter que lorsque vous modifiez votre classe d'instance DB ou stockage attribué, les changements demandés seront appliqués pendant la fenêtre de maintenance spécifiée. Vous pouvez aussi utiliser l'indicateur « appliquer-immédiatement » pour appliquer immédiatement vos demandes de dimensionnement. N'oubliez pas que tout changement de système en attente sera également appliqué.

Surveillez l'utilisation des ressources de calcul et de mémoire de votre instance DB, gratuitement, via Amazon CloudWatch. Vous pouvez accéder aux mesures telles que l'utilisation de la CPU, l'utilisation de stockage et le trafic du réseau en cliquant sur l'onglet « Monitoring » pour votre instance DB dans AWS Management Console ou en utilisant les API d'Amazon CloudWatch. Pour en savoir plus sur la surveillance de vos instances DB actives, lisez le manuel Amazon RDS User Guide.

Concernant SQL Server, veuillez noter qu'en raison des limites d'extensibilité du stockage par bandes associé à l'environnement Windows Server, à l'heure actuelle Amazon RDS ne prend pas en charge l'augmentation du volume de stockage. Bien que nous envisagions d'intégrer cette fonctionnalité à l'avenir, nous vous recommandons d'allouer le stockage en fonction de vos prévisions de croissance du stockage. Entre-temps, si vous devez augmenter l'espace de stockage d'une instance DB SQL Server, vous devez en exporter les données, créer une autre instance DB plus volumineuse et y réimporter les données. Pour en savoir plus, reportez-vous au guide relatif à l'importation des données pour SQL Server.

Q : Quelle est la configuration matérielle requise pour le stockage Amazon RDS ?

Amazon RDS utilise les volumes EBS pour la base de données et le stockage de journal. En fonction de la taille de stockage demandée, Amazon RDS ajuste automatiquement sur plusieurs volumes EBS pour améliorer la performance IOPS. Pour MySQL et Oracle, sur une instance DB existante, vous pouvez observer une amélioration de la capacité en I/O si vous redimensionnez votre volume de stockage. Vous pouvez redimensionner la capacité de stockage allouée à votre instance DB en utilisant AWS Management Console, l'API ModifyDBInstance ou la commande rds-modify-db-instance.

En revanche, dans le cas de SQL Server, en raison des limites d'extensibilité du stockage par bandes associé à l'environnement Windows Server, Amazon RDS ne prend actuellement pas en charge l'augmentation du volume de stockage.

Pour en savoir plus, voir Stockage Amazon RDS.

Q : Mon instance DB restera-t-elle disponible pendant le dimensionnement ?

La capacité de stockage de votre instance DB peut être augmentée tout en maintenant la disponibilité de l'instance DB. Toutefois, lorsque vous décidez de dimensionner les ressources de calcul disponibles vers votre instance DB, votre base de données sera temporairement indisponible pendant la modification de la classe d'instance DB. Cette période d'indisponibilité ne dure généralement que quelques minutes et aura lieu pendant la fenêtre de maintenance pour votre instance DB, sauf si vous indiquez que la modification doit être appliquée immédiatement.

Q : Comment puis-je dimensionner mon instance DB au-delà de la classe d'instances DB la plus élevée et des capacités de stockage maximales ?

Amazon RDS prend en charge un éventail de classes d'instance DB et d'attributions de stockage pour répondre aux différents besoins des applications. Si votre application a besoin de plus de ressources de calcul que la classe d'instance DB la plus importante ou plus de stockage que l'attribution maximale, vous pouvez implémenter le partitionnement, diffusant ainsi vos données dans des instances DB multiples.

Q : Qu'est-ce que le stockage à usage général (SSD) Amazon RDS ?

Le stockage à usage général (SSD) Amazon RDS convient à un large éventail de charges de travail de base de données dont les besoins en matière d'E/S sont modérés. Présentant une ligne de base de 3 IOPS/Go, avec la possibilité d'atteindre des pics de 3 000 IOPS, cette option de stockage offre des performances prévisibles qui répondent aux besoins de la plupart des applications.

Q : Qu'est-ce que le stockage IOPS dimensionné (SSD) Amazon RDS ?

Le stockage IOPS dimensionné (SSD) Amazon RDS est une option de stockage SSD conçue pour fournir des performances I/O rapides, prévisibles et constantes. Avec ce type de stockage, vous pouvez définir un taux d'E/S par seconde lors de la création d'une instance DB. Amazon RDS prévoit ce taux d'E/S par seconde pour toute la durée de vie de l'instance DB. Le stockage IOPS dimensionné (SSD) Amazon RDS est optimisé pour les charges de travail de base de données transactionnelles (OLTP) à fort taux d'E/S. Pour plus d'informations, consultez le manuel de l'utilisateur Amazon RDS User Guide.

Q : Qu'est-ce que le stockage de type magnétique Amazon RDS ?

Le stockage de type magnétique Amazon RDS s'avère utile pour les petites charges de travail de base de données où l'accès aux données est plus rare. Le stockage de type magnétique n'est pas recommandé pour les instances de base de données de production.

Q : Comment effectuer un choix parmi les types de stockages Amazon RDS ?

Choisissez le type de stockage le plus adapté à votre charge de travail.

  • Charges de travail de base de données transactionnelles (OLTP) à hautes performances : Stockage IOPS dimensionné (SSD) Amazon RDS
  • Charges de travail de base de données ayant des besoins modérés en matière d'E/S : Stockage à usage général (SSD) Amazon RDS

Q : Quels sont les volumes IOPS minimum et maximum pris en charge par Amazon RDS ?

Les volumes IOPS pris en charge par Amazon RDS varient en fonction du moteur de base de données. Pour plus d'informations, consultez le manuel de l'utilisateur Amazon RDS User Guide.

Q : Quelle est la différence entre les sauvegardes RDS automatisées et les snapshots DB ?

Amazon RDS fournit deux méthodes différentes de sauvegarde et de restauration de vos sauvegardes automatisées et instantanés de base de données (snapshots DB) de votre/vos instances DB.

La fonction de sauvegarde automatisée d'Amazon RDS permet la restauration à un instant dans le passé de votre instance de base de données. Lorsque les sauvegardes automatisées sont activées pour votre instance de base de données, Amazon RDS réalise automatiquement un instantané quotidien complet de vos données (pendant votre fenêtre de sauvegarde préférée) et capture les journaux de transaction (au fur et à mesure des mises à jour de votre instance de base de données). Lorsque vous effectuez une restauration à un instant dans le passé, les journaux de transaction sont appliqués à la sauvegarde quotidienne la plus appropriée, afin de restaurer votre instance DB à l'instant précis souhaité. Amazon RDS conserve les sauvegardes d'une instance de base de données pendant une période de temps limitée et spécifiée par l'utilisateur, la période de rétention, qui est de 7 jours par défaut, mais qui peut être définie jusqu'à 35 jours. Vous pouvez lancer une restauration à un moment donné et spécifier n'importe quelle seconde pendant votre période de rétention, jusqu'au point du dernier moment restaurable. Vous pouvez utiliser l'API DescribeDBInstances pour revenir au dernier moment restaurable pour votre instance DB, qui est généralement situé dans les cinq dernières minutes. Alternativement, vous pouvez trouver le Dernier moment restaurable pour une instance DB en le sélectionnant dans AWS Management Console et en cherchant dans l'onglet « Description » dans le panneau inférieur de la Console.

Les snapshots DB sont lancés par l'utilisateur et vous permettent de sauvegarder votre instance DB dans un état connu aussi fréquemment que vous le souhaitez, puis de la restaurer à cet état spécifique à tout moment. Les snapshots DB peuvent être créés à l'aide d'AWS Management Console, de l'API CreateDBSnapshot ou de la commande create-db-snapshot, et sont conservés jusqu'à ce que vous les supprimiez explicitement.

Les instantanés effectués par Amazon RDS pour l'activation des sauvegardes automatisées sont à votre disposition pour copie (à l'aide de la console AWS ou de la commande copy-db-snapshot) ou pour la fonctionnalité de restauration d'instantané. Vous pouvez les identifier à l'aide du type d'instantané « automatisé ». De plus, vous pouvez identifier l'heure à laquelle l'instantané a été pris en consultant le champ Heure de création de l'instantané. Sachez que l'identifiant des instantanés « automatisés » contient également l'heure (temps universel coordonné) à laquelle l'instantané a été pris.

Remarque : lorsque vous réalisez une opération de restauration vers un moment donné ou depuis un snapshot DB, une nouvelle instance DB est créée avec un nouveau point de terminaison (l'ancienne instance DB peut être supprimée si vous le souhaitez). Vous pouvez ainsi créer des instances DB multiples à partir d'un snapshot DB spécifique ou d'un moment donné.

Q : Ai-je besoin d'activer les sauvegardes pour mon instance DB ou cela se fait-il automatiquement ?

Par défaut, Amazon RDS active la sauvegarde automatique de votre instance de base de données avec une période de rétention de 7 jours. Le stockage de sauvegarde gratuit est limité à la taille de votre base de données mise en service et s'applique uniquement aux instances de base de données actives. Par exemple, si vous avez 100 Go de stockage de base de données alloués en un mois, nous offrons 100 Go par mois de stockage de sauvegarde sans frais supplémentaires. Si vous souhaitez augmenter votre période de rétention de sauvegarde au-delà d'une journée, ceci est réalisable en utilisant l'API CreateDBInstance (pour la création d'une nouvelle instance DB) ou l'API ModifyDBInstance (pour une instance DB existante). Vous pouvez utiliser ces API pour changer le paramètre RetentionPeriod de 1 à un nombre souhaité de jours. Pour plus d'informations sur les sauvegardes automatisées, consultez le manuel Amazon RDS User Guide.

Q : Qu'est-ce qu'une fenêtre de sauvegarde et pourquoi en ai-je besoin ? Ma base de données est-elle disponible pendant la fenêtre de sauvegarde ?

La fenêtre de sauvegarde préférée est la période de temps définie par l'utilisateur pendant laquelle votre instance DB est sauvegardée. Amazon RDS utilise ces sauvegardes de données périodiques avec vos journaux de transactions pour vous permettre de restaurer votre instance DB à n'importe quelle seconde pendant votre période de rétention, jusqu'au LatestRestorableTime (en général jusqu'aux cinq dernières minutes). Pendant la période de sauvegarde, les E/S de stockage peuvent être brièvement interrompues lors de l'initialisation du processus de sauvegarde (généralement pendant quelques secondes), et il est possible qu'une latence plus élevée se fasse brièvement ressentir. Les déploiements DB Multi-AZ ne subissent aucune période de suspension d'E/S, car la sauvegarde est réalisée à partir de l'instance de secours.

Q : Où sont stockés mes instantanés DB et mes sauvegardes automatiques, et comment puis-je gérer leur conservation ?

Les snapshots DB et sauvegardes automatiques Amazon RDS sont stockés dans S3.

Vous pouvez utiliser AWS Management Console, l'API ModifyDBInstance ou la commande modify-db-instance pour gérer la période pendant laquelle vos sauvegardes automatisées sont conservées en modifiant le paramètre RetentionPeriod. Si vous souhaitez désactiver complètement les sauvegardes automatisées, vous pouvez définir la période de rétention sur 0 (bien que cette option ne soit pas recommandée). Vous pouvez gérer vos snapshots DB crées par l'utilisateur via la section « Snapshots » de la console Amazon RDS. Vous pouvez également consulter la liste des snapshots DB créés par l'utilisateur pour une instance DB donnée en utilisant l'API DescribeDBSnapshots ou la commande describe-db-snapshots et supprimer les instantanés avec l'API DeleteDBSnapshot ou la commande delete-db-snapshot.

Q : Qu'arrive-t-il à mes sauvegardes et instantanés DB si je supprime mon instance DB ?

Lorsque vous supprimez une instance DB, vous pouvez créer un instantané DB final au moment de la suppression ; de cette manière, vous pourrez utiliser cet instantané DB pour restaurer ultérieurement l'instance DB supprimée. Amazon RDS conserve cet instantané DB final créé par l'utilisateur avec les autres instantanés DB créés manuellement et ce, même après la suppression de l'instance DB. Consultez la page de tarification pour en savoir plus sur les coûts de stockage des sauvegardes.

Les sauvegardes automatiques sont supprimées en même temps que l'instance DB. Seuls les instantanés DB créés manuellement sont conservés après la suppression de l'instance DB.


Q : Qu'est-ce qu'Amazon Virtual Private Cloud (VPC) et comment fonctionne-t-il avec Amazon RDS ?

Amazon VPC vous permet de créer un environnement de mise en réseau virtuel dans une section privée et isolée du cloud AWS, où vous pouvez exercer un contrôle total sur les aspects tels que les plages d'adresses IP privées, les sous-réseaux, les tables de routage et les passerelles réseau. Avec Amazon VPC, vous pouvez définir une topologie de réseau virtuel et personnaliser la configuration réseau afin qu'elle ressemble étroitement à un réseau IP classique que vous pourriez exploiter dans votre propre centre de données.

Les avantages du VPC peuvent vous profiter lorsque vous souhaitez exécuter une application Web destinée au grand public tout en conservant des serveurs backend non accessibles au public dans un sous-réseau privé. Vous pouvez créer un sous-réseau destiné au grand public pour vos serveurs Web avec accès à Internet et placer vos instances de base de données RDS back-end dans un sous-réseau privé sans accès Internet. Pour en savoir plus sur Amazon VPC, consultez le manuel Amazon Virtual Private Cloud User Guide.

Q : En quoi l'utilisation d'Amazon RDS au sein d'un VPC diffère-t-elle de celle sur la plate-forme EC2-Classic (en dehors d'un VPC) ?

Si vous avez créé votre compte AWS avant le 04/12/2013, il se peut que vous puissiez exécuter Amazon RDS dans un environnement Amazon Elastic Compute Cloud (EC2)–Classic. La fonctionnalité de base d'Amazon RDS est la même, que VPC EC2–Classic ou EC2 soit ou non utilisé. Amazon RDS gère les sauvegardes, l'application des correctifs logiciels, la détection automatique des pannes, la lecture des réplicas et la restauration, que vos instances DB soient déployées dans ou en dehors d'un VPC. Pour plus d'informations sur les différences entre EC2-Classic et EC2-VPC, consultez la documentation d'EC2.

Q : Qu'est-ce qu'un groupe de sous-réseaux DB et pourquoi en ai-je besoin ?

Un groupe de sous-réseau de base de données est un ensemble de sous-réseaux que vous pouvez désigner pour vos instances de base de données RDS dans un cloud privé virtuel. Chaque groupe de sous-réseau de base de données doit posséder au minimum un sous-réseau pour chaque zone de disponibilité d'une région donnée. Lors de la création d'une instance de base de données dans VPC, vous devez sélectionner un groupe de sous-réseau de base de données. Amazon RDS utilise ensuite le groupe de sous-réseau de base de données et votre zone de disponibilité préférée pour sélectionner un sous-réseau et une adresse IP dans ce sous-réseau. Amazon RDS crée et associe une interface Elastic Network Interface à votre instance de base de données avec cette adresse IP.

Sachez que nous vous recommandons vivement d'utiliser le nom DNS pour la connexion à votre instance de base de données, car l'adresse IP sous-jacente peut être modifiée (par exemple pendant un basculement).

Pour les déploiements Multi-AZ, la définition d'un sous-réseau pour toutes les zones de disponibilité d'une région permet à Amazon RDS de créer une nouvelle mise en attente dans une autre zone de disponibilité en cas de besoin. Vous devez procéder de la sorte même pour les déploiements Single-AZ, au cas où vous souhaitiez les convertir en déploiements Multi-AZ par la suite.

Q : Comment créer une instance DB Amazon RDS dans VPC ?

Pour voir la procédure explicative de ce processus, consultez la section Création d'une instance DB dans un VPC du guide de l'utilisateur Amazon RDS.

Q : Comment contrôler l'accès du réseau à mon/mes instance(s) DB ?

Consultez la section Security Groups du manuel Amazon RDS User Guide afin d'en savoir plus sur les différentes façons de contrôler l'accès à vos instances de base de données.

Q : Comment puis-je me connecter à une instance DB RDS dans VPC ?

Les instances de base de données déployées dans un cloud privé virtuel sont accessibles par les instances EC2 déployées dans le même cloud privé virtuel. Si ces instances EC2 sont déployées dans un sous-réseau public avec des adresses IP Elastic associées, vous pouvez accéder aux instances EC2 sur Internet.

Les instances DB déployées dans un VPC sont accessibles depuis Internet ou depuis les instances EC2 en dehors du VPC via une connexion VPN ou des bastions Internet que vous pouvez lancer dans votre sous-réseau public, ou encore en utilisant l'option d'accès public d'Amazon RDS :

  • Pour utiliser un bastion Internet, vous devez configurer un sous-réseau public dans une instance EC2 faisant office de bastion SSH. Ce sous-réseau public doit disposer d'une passerelle Internet et de règles de routage autorisant la direction du trafic via l'hôte SSH, qui doit à son tour transférer les requêtes vers l'adresse IP privée de votre instance de base de données RDS.
  • Pour utiliser une connexion publique, il vous suffit de créer vos instances DB en activant l'option d'accès public. Lorsque l'option d'accès public est activée, vos instances DB se trouvant dans un VPC sont entièrement accessibles en dehors de votre VPC par défaut. Autrement dit, vous n'avez pas à configurer de VPN ou de bastion Internet pour pouvoir accéder à vos instances.

Vous pouvez également configurer une passerelle de réseau privé virtuel en extension de votre réseau d'entreprise vers votre nuage privé virtuel et autoriser l'accès à l'instance de base de données RDS dans ce nuage privé virtuel. Veuillez vous reporter au manuel Amazon VPC User Guide pour plus de détails.

Nous vous recommandons vivement d'utiliser le nom DNS pour la connexion à votre instance de base de données, car l'adresse IP sous-jacente peut être modifiée (par exemple pendant un basculement).

Q : Puis-je déplacer vers mon VPC mes instances DB existantes extérieures ?

Si votre instance DB n'est pas dans un VPC, vous pouvez utiliser AWS Management Console pour déplacer facilement votre instance DB vers un VPC. Pour en savoir plus, consultez le manuel Amazon RDS User Guide. Vous pouvez également prendre un instantané de votre instance DB en dehors de VPC et le restaurer dans VPC en spécifiant le groupe de sous-réseaux DB que vous souhaitez utiliser. Vous pouvez également effectuer une opération Restore to Point in Time (Restaurer à un instant précis).

Q : Puis-je déplacer hors du VPC les instances DB existantes qui s'y trouvent ?

La migration des instances DB depuis VPC en dehors de VPC n'est pas prise en charge. Pour des raisons de sécurité, un snapshot DB d'une instance DB dans VPC ne peut pas être restauré en dehors de VPC. Il en va de même pour la fonctionnalité Restore to Point in Time (Restaurer à un instant précis). 

Q : Quelles précautions dois-je prendre pour m'assurer que mes instances de base de données dans VPC sont accessibles par mon application ?

Vous avez la responsabilité de la modification des tables de routage et des listes de droits d'accès réseau dans votre cloud privé virtuel afin de vous assurer que votre instance de base de données peut être atteinte depuis vos instances clientes du cloud privé virtuel.

Pour les déploiements Multi-AZ, après un basculement, il est possible que votre instance EC2 cliente et l'instance de base de données RDS se trouvent dans des zones de disponibilité différentes. Vous devez configurer vos listes de droits d'accès réseau afin de vous assurer que la communication cross-AZ est possible.

Q : Puis-je modifier le groupe de sous-réseau de base de données de mon instance DB ?

Un groupe de sous-réseaux de base de données existant peut être mis à jour afin d'ajouter des sous-réseaux supplémentaires, soit pour les zones de disponibilité existantes, soit pour les zones de disponibilité ajoutées depuis la création de l'instance DB. En retirant des sous-réseaux d'un groupe de sous-réseaux DB existant, vous risquez de rendre indisponibles les instances s'exécutant dans une zone de disponibilité supprimée du groupe de sous-réseaux. Pour en savoir plus, consultez le guide de l'utilisateur Amazon RDS.

Q : Qu'est-ce qu'un compte d'utilisateur principal Amazon RDS et en quoi est-il différent d'un compte AWS ?

Pour commencer à utiliser Amazon RDS, vous aurez besoin d'un compte de développeur AWS. Si vous n'en aviez pas avant de vous inscrire à Amazon RDS, vous serez invité à en créer un au début de la procédure d'inscription. Un compte d'utilisateur principal est différent d'un compte de développeur AWS et il n'est utilisé que dans le contexte d'Amazon RDS pour contrôler l'accès à votre/vos instances DB. Le compte d'utilisateur principal est un compte d'utilisateur de base de données native que vous pouvez connecter à votre instance DB. Vous pouvez spécifier le nom de l'utilisateur principal et le mot de passe que vous voulez associer à chaque instance DB lorsque vous créez l'instance DB. Une fois que vous avez créé votre instance DB, vous pouvez vous connecter à la base de données en utilisant les identifiants de l'utilisateur principal. Par la suite, vous pourriez également vouloir créer des comptes d'utilisateur supplémentaires, afin de pouvoir limiter l'accès des personnes à votre instance DB.

Q : Quels privilèges sont accordés à l'utilisateur principal concernant mon instance DB ?

Pour MySQL, les privilèges par défaut de l'utilisateur principal incluent : créer, abandonner, références, évènement, modifier, supprimer, indexer, insérer, sélectionner, mettre à jour, créer des tables temporaires, verrouiller des tables, déclencher, créer un affichage, afficher, modifier une routine, créer une routine, exécuter, créer un utilisateur, traiter, afficher des bases de données, accorder une option.

Pour Oracle, l'utilisateur principal reçoit le rôle « dba ». L'utilisateur principal hérite de la plupart des privilèges associés au rôle. Reportez-vous au manuel Amazon RDS User Guide afin de consulter la liste des privilèges restreints et les alternatives correspondantes pour effectuer les tâches administratives pouvant nécessiter de tels privilèges.

Avec SQL Server, un utilisateur qui crée une base de données reçoit le rôle « db_owner ». Reportez-vous au manuel Amazon RDS User Guide afin de consulter la liste des privilèges restreints et les alternatives correspondantes pour effectuer les tâches administratives pouvant nécessiter de tels privilèges.

Q : La gestion des utilisateurs diffère-t-elle avec Amazon RDS ?

Non, tout fonctionne comme vous en avez l'habitude avec une base de données relationnelle que vous gérez par vous-même.

Q : Les programmes exécutés sur des serveurs dans mon propre centre de données peuvent-il accéder aux bases de données Amazon RDS ?

Oui. Vous devez explicitement activer l'accès à votre base de données via Internet en configurant des groupes de sécurité. Vous pouvez autoriser l'accès uniquement pour des adresses IP spécifiques, des plages d'adresses IP ou des sous-réseaux correspondant aux serveurs de votre propre centre de données.

Q : Puis-je chiffrer les connexions entre mon application et mon instance DB à l'aide du protocole SSL ?

Oui, cette option est actuellement prise en charge pour les moteurs MySQL, MariaDB, SQL Server, PostgreSQL et Oracle.

Amazon RDS génère un certificat SSL pour chaque instance DB. Une fois qu'une connexion chiffrée est établie, les données transférées entre l'instance DB et votre application seront chiffrées pendant le transfert.

Bien que SSL offre des avantages en termes de sécurité, notez que le chiffrement SSL est une opération de calcul intensive, qui augmentera les temps de latence de la connexion de votre base de données. La prise en charge SSL dans Amazon RDS est destinée au chiffrement de la connexion entre votre application et votre instance DB ; vous ne devez pas vous reposer sur elle pour authentifier l'instance DB elle-même.

Pour en savoir plus sur la mise en place d'une connexion chiffrée à Amazon RDS, consultez les manuels Amazon RDS MySQL User Guide, MariaDB User Guide, SQL Server User Guide, PostgreSQL User Guide ou Oracle User Guide. Pour plus d'informations sur le fonctionnement de SSL avec ces différents moteurs, vous pouvez consulter directement la documentation MySQL, la documentation MariaDB, la documentation MSDN SQL Server, la documentation PostgreSQL ou la documentation Oracle.

Q : Puis-je chiffrer des données au repos dans mes bases de données Amazon RDS ?

Amazon RDS prend en charge le chiffrement au repos pour tous les moteurs de base de données, à l'aide des clés que vous gérez via AWS Key Management Service (KMS). Sur une instance de base de données en cours d'exécution utilisant le chiffrement Amazon RDS, les données stockées au repos dans le stockage sous-jacent sont chiffrées, tout comme ses sauvegardes automatiques, ses réplicas en lecture et ses instantanés. Le chiffrement et le déchiffrement sont gérés de manière transparente. Pour plus d'informations concernant l'utilisation de KMS avec Amazon RDS, consultez le manuel Amazon RDS User's Guide.

Il est également possible d'ajouter un chiffrement à une instance ou un cluster DB non chiffré en capturant un Snapshot DB, puis en créant une copie de cet instantané et en spécifiant une clé de chiffrement KMS. Vous pouvez ensuite restaurer une instance ou un cluster DB chiffré à partir de l'instantané chiffré.

Amazon RDS pour Oracle et SQL Server prennent en charge les technologies de chiffrement transparent des données de ces moteurs. Dans Oracle, le chiffrement transparent des données est intégré à AWS CloudHSM, ce qui vous permet de générer, stocker et gérer vos clés cryptographiques en toute sécurité sur des appliances HSM (Hardware Security Module ou Module de sécurité matérielle) en location exclusive au sein du cloud AWS. Pour plus d'informations, consultez les sections du manuel Amazon RDS User's Guide consacrées à Oracle et à SQL Server.

Q : Comment contrôler les opérations que mes systèmes et utilisateurs peuvent effectuer sur des ressources RDS spécifiques ?

Vous pouvez contrôler les opérations que vos groupes et utilisateurs AWS IAM sont autorisés à effectuer sur les ressources RDS. Pour ce faire, vous devez référencer les ressources RDS en question dans les politiques AWS IAM appliquées à vos groupes et utilisateurs. Les ressources RDS pouvant être référencées dans une politique AWS IAM incluent les instances DB, les instantanés DB, les réplicas en lecture, les groupes de sécurité DB, les groupes d'options DB, les groupes de paramètres DB, les abonnements à des événements et les groupes de sous-réseaux DB. En outre, vous pouvez associer des mots-clés à ces ressources pour leur ajouter des métadonnées supplémentaires. Les mots-clés vous permettent de classer vos ressources (par exemple : instances DB de « développement », de « production », de « test»...) et de créer des politiques AWS IAM répertoriant des autorisations (actions pouvant être effectuées) pour toutes les ressources comportant les mêmes mots-clés. Pour en savoir plus, consultez les sections Managing Access to Your Amazon RDS Resources and Databases et Tagging Amazon RDS Resources du manuel Amazon RDS User Guide.

Q : Je souhaite réaliser une analyse de sécurité ou un dépannage opérationnel de mon déploiement RDS. Puis-je obtenir un historique de tous les appels d'API RDS effectués depuis mon compte ?

Oui. AWS CloudTrail est un service Web qui enregistre les appels d'API AWS pour votre compte et vous les présente sous forme de fichier journal. L'historique des appels d'API AWS généré par CloudTrail permet de réaliser une analyse de sécurité, le suivi des modifications au niveau des ressources, ainsi que l'audit de conformité. Pour en savoir plus sur ce service, consultez la page de présentation détaillée d'AWS CloudTrail ; pour l'activer, rendez-vous sur la page d'accueil d'AWS Management Console pour CloudTrail.


Q : Comment choisir les bons paramètres de configuration pour mon/mes instance(s) DB ?

Par défaut, Amazon RDS choisit les paramètres de configuration optimaux pour votre instance DB en prenant en compte la classe d'instance et la capacité de stockage. Cependant, si vous souhaitez les modifier, vous pouvez le faire en utilisant AWS Management Console, les API Amazon RDS ou l'interface de ligne de commande AWS. Veuillez noter que changer les paramètres de configuration à partir des valeurs recommandées peut avoir des effets inattendus, allant d'une performance dégradée aux plantages de système ; ceci ne doit être effectué que par des utilisateurs avancés qui sont disposés à assumer ces risques.

Q : En quoi consistent les groupes de paramètres DB ? En quoi sont-ils utiles ?

Un groupe de paramètres de base de données (Groupe de paramètre DB) agit en tant que « conteneur » pour les valeurs de configuration de moteur qui peuvent être appliquées à une ou plusieurs instances DB. Si vous créez une instance DB sans spécifier un groupe de paramètre DB, un groupe de paramètre DB par défaut est utilisé. Ce groupe par défaut contient le moteur par défaut et le système Amazon RDS par défaut optimisés pour l'instance DB que vous exécutez. Toutefois, si vous voulez que votre instance DB soit exécutée avec vos valeurs de configuration de moteur sur mesure, il vous suffit de créer un nouveau groupe de paramètres DB, modifier les paramètres souhaités et l'instance DB pour utiliser le nouveau groupe de paramètres DB. Une fois associées, toutes les instances DB qui utilisent un Parameter Group DB particulier peuvent obtenir toutes les mises à niveau de paramètre vers ce Parameter Group DB.

Pour plus d'informations sur la configuration des Parameter Group DB, lisez le manuel Amazon RDS User Guide.

Q : Comment surveiller la configuration de mes ressources Amazon RDS ?

Vous pouvez utiliser AWS Config pour enregistrer en continu les changements de configuration apportés aux instances DB Amazon RDS, aux groupes de sous-réseaux DB, aux snapshots DB, aux groupes de sécurité DB et aux abonnements aux événements, et recevoir une notification de changement via Amazon Simple Notification Service (SNS). Vous pouvez également créer des règles AWS Config pour déterminer si ces ressources RDS présentent les configurations souhaitées.  


Q : Quels types de réplication sont pris en charge par Amazon RDS et quand dois-je les utiliser ?

Amazon RDS propose deux options de réplication distinctes pour répondre à différents besoins.

Si vous cherchez à utiliser la réplication pour augmenter la disponibilité de la base de données, tout en protégeant vos dernières mises à jour de base de données contre des interruptions non planifiées, nous recommandons d'exécuter votre instance DB en tant que déploiement Multi-AZ. Lorsque vous créez ou modifiez votre instance DB afin qu'elle soit exécutée en tant que déploiement Multi-AZ, Amazon RDS met en service et gère un réplica « de secours » dans une zone de disponibilité différente (infrastructure indépendante dans un lieu physiquement séparé). En cas de maintenance de base de données programmée, de défaillance d'instance DB ou de défaillance de zone de disponibilité, Amazon RDS basculera automatiquement vers l'instance de secours, afin que les opérations de la base de données puissent reprendre rapidement sans intervention administrative. Les déploiements Multi-AZ utilisent la réplication synchrone, où les écritures de base de données sont faites simultanément sur les deux instances principale et de secours, afin que l'instance de secours soit à jour, en cas de basculement. Tandis que notre implémentation technologique pour les instances DB multi-AZ maximise la durabilité des données en cas de scénarios de défaillance, elle exclut l'accès direct à l'instance de secours ou son utilisation pour les opérations en lecture. La tolérance de panne offerte par les déploiements multi-AZ en font le choix naturel pour les environnements de production.

Pour vous permettre de procéder à un dimensionnement au-delà des contraintes de capacités d'une seule instance DB pour les charges de travail de base de données à lecture intensive, Amazon RDS propose les réplicas en lecture. Vous pouvez créer un réplica en lecture d'une instance DB source donnée à l'aide d'AWS Management Console, de l'API RDS ou de l'interface de ligne de commande AWS. Une fois que le réplica en lecture est créé, les mises à jour de base de données sur l'instance DB source seront propagées sur le réplica en lecture. Vous pouvez créer plusieurs réplicas en lecture pour une instance DB source donnée et répartir le trafic en lecture de votre application sur ces réplicas.

Les réplicas en lecture sont pris en charge par Amazon Aurora, Amazon RDS for MySQL, MariaDB et PostgreSQL. A la différence des déploiements multi-AZ, les réplicas en lecture pour ces moteurs utilisent la technologie de réplication intégrée et profitent de ses points forts, mais subissent également ses limitations. En particulier, les mises à jour sont appliquées à votre/vos réplicas en lecture après qu'elles aient eu lieu sur l'instance DB source (réplication « asynchrone ») et le retard de réplication peut varier de manière importante. Ceci signifie que les mises à jour récentes de base de données sur une instance DB source standard (autre que Multi-AZ) peuvent ne pas être présentes sur les réplicas en lecture associés en cas d'interruption non planifiée sur l'instance DB source. A ce titre, les réplicas en lecture n'offrent pas les mêmes avantages de durabilité de données que les déploiements Multi-AZ. Tandis que les réplicas en lecture peuvent fournir certains avantages en matière de disponibilité en lecture, ils ne sont pas conçus pour améliorer la disponibilité d'écriture.

Vous pouvez utiliser les déploiements multi-AZ conjointement avec les réplicas en lecture pour profiter des avantages complémentaires de chacun. Vous pouvez simplement spécifier qu'un déploiement Multi-AZ donné est l'instance DB source pour votre/vos réplicas en lecture. De cette manière vous bénéficiez de la disponibilité et de la durabilité des données des déploiements Multi-AZ et du dimensionnement en lecture des réplicas en lecture.

Q : Que signifie exécuter une instance DB en tant que déploiement multi-AZ ?

Lorsque vous créez ou modifiez votre instance DB afin qu'elle soit exécutée en tant que déploiement Multi-AZ, Amazon RDS met en service et maintient automatiquement un réplica « de secours » synchrone dans une zone de disponibilité différente. Les mises à jour vers votre instance DB sont répliquées de manière synchrone sur les zones de disponibilité vers l'instance de secours, afin qu'elles restent toutes deux synchronisées et qu'elles protègent vos dernières mises à jour de base de données contre une défaillance d'instance DB. Pendant certains types de maintenance planifiée ou dans le cas improbable d'une défaillance d'instance DB ou de zone de disponibilité, Amazon RDS basculera automatiquement vers l'instance de secours, afin que vous puissiez continuer les écritures et lectures vers la base de données dès que l'instance de secours est activée. Etant donné que l'enregistrement de nom de votre instance DB reste le même, votre application peut reprendre les opérations de base de données sans qu'une intervention administrative manuelle ne soit nécessaire. Avec les déploiements Multi-AZ, la réplication est transparente : vous n'interagissez pas directement avec l'instance de secours et elle ne peut pas être utilisée pour servir le trafic en lecture. Pour en savoir plus sur les déploiements multi-AZ, consultez le manuel Amazon RDS User Guide.

Q : Qu'est-ce qu'une zone de disponibilité ?

Les zones de disponibilité sont des emplacements distincts dans une région conçues pour être isolées des défaillances dans d'autres zones de disponibilité. Chaque zone de disponibilité exécute sa propre infrastructure indépendante et physiquement distincte et est conçue pour être hautement fiable. Les points communs de défaillance, tels que les générateurs et équipements de refroidissement ne sont pas partagés parmi les zones de disponibilité. En outre, ils sont physiquement séparés ; ainsi même un désastre rare, comme un incendie, une tempête ou une inondation, n'affecterait qu'une seule zone de disponibilité. Les zones de disponibilité dans la même région bénéficient d'une connectivité de réseau avec une faible latence.

Q : Que signifient « principal » et « de secours » dans le contexte d'un déploiement multi-AZ ?

Lorsque vous exécutez une instance DB en tant que déploiement Multi-AZ, l'instance « principale » sert les écritures et lectures de base de données. En outre, Amazon RDS prévoit et maintient une instance de « secours » en arrière-plan, qui est un réplica à jour de l'instance principale. L'instance de secours est « promue » en cas de scénario de basculement. Après le basculement, l'instance secours devient l'instance principale et accepte vos opérations de base de données. Vous n'interagissez pas directement avec l'instance de secours (par ex. pour les opérations en lecture) à un moment quelconque avant la promotion. Si vous souhaitez dimensionner vos capacités de trafic en lecture au-delà des contraintes liées à une instance DB unique, consultez les FAQ sur les réplicas en lecture.

Q : Quels sont les avantages d'un déploiement multi-AZ ?

Les avantages principaux de l'exécution de votre instance DB en tant que déploiement Multi-AZ sont une durabilité et une disponibilité de la base de données améliorées. La disponibilité améliorée et la tolérance de panne offertes par les déploiements Multi-AZ en font le choix naturel pour les environnements de production.

En exécutant votre instance DB sous forme de déploiement Multi-AZ, vos données sont protégées dans le cas, peu probable, d'une défaillance d'un composant d'une instance DB ou d'une perte de disponibilité dans une zone de disponibilité. Par exemple, si un volume de stockage sur l'instance principale connaît une défaillance, Amazon RDS déclenche automatiquement un basculement vers l'instance de secours, où toutes vos mises à jour de base de données sont intactes. Ceci fournit une durabilité des données supplémentaire relativement aux déploiements standards dans une seule AZ, où une opération de restauration lancée par un utilisateur serait requise et les mises à jour qui ont eu lieu après le dernier moment restaurable (en général dans les cinq dernières minutes) ne seraient pas disponibles.

Vous profitez également d'une disponibilité de base de données améliorée lorsque votre instance DB est exécutée en tant que déploiement Multi-AZ. Si une défaillance de zone de disponibilité ou d'instance DB se produit, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement. Les avantages de la disponibilité Multi-AZ s'étendent également jusqu'à la maintenance planifiée. Par exemple, avec les sauvegardes automatisées, l'activité E/S n'est plus suspendue sur votre instance principale pendant la fenêtre de sauvegarde préférée, car les sauvegardes sont prises depuis l'instance de secours. Dans le cas d'une correction ou d'un dimensionnement de classe d'instance DB, ces opérations ont lieu tout d'abord sur l'instance de secours, avant le basculement automatique. En conséquence, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement.

Un autre avantage implicite d'exécuter votre instance DB en tant que déploiement Multi-AZ est le fait que le basculement d'instance DB est automatique et ne nécessite pas d'administration. Dans un contexte Amazon RDS, ceci signifie que vous n'avez pas besoin de surveiller les événements d'instance DB et de lancer une récupération d'instance DB manuelle (via les API RestoreDBInstanceToPointInTime ou RestoreDBInstanceFromSnapshot) en cas de défaillance de zone de disponibilité ou d'instance DB.

Q : L'exécution de mon instance DB en tant que déploiement multi-AZ a-t-elle des répercussions sur les performances ?

Vous pouvez observer des temps de latence élevés par rapport à un déploiement d'instance DB standard dans une seule zone de disponibilité, du fait de la réplication synchrone des données qui est réalisée.

Q : Lorsque j'exécute mon instance DB en tant que déploiement multi-AZ, puis-je utiliser le réplica de secours pour les opérations en lecture ou d'écriture ?

Non, le réplica de secours ne peut pas servir les demandes en lecture. Les déploiements Multi-AZ sont conçus pour fournir une disponibilité et durabilité de base de données améliorées, plutôt que les avantages de dimensionnement en lecture. À ce titre, la fonction utilise la réplication synchrone entre les instances principales et de secours. Notre implémentation veille à ce que les instances principales et de secours soient constamment synchronisés, mais exclut l'utilisation de l'instance de secours pour les opérations en lecture ou écriture. Si une solution de dimensionnement en lecture vous intéresse, consultez les FAQ sur les réplicas en lecture.

Q : Comment configurer un déploiement d'instance DB multi-AZ ?

Afin de créer un déploiement d'instance DB Multi-AZ, il suffit de cliquer sur l'option « Yes » pour un « déploiement Multi-AZ » lors du lancement d'une instance DB avec AWS Management Console. De manière alternative, si vous utilisez les API Amazon RDS, vous appelez l'API CreateDBInstance et définissez le paramètre « Multi-AZ » sur la valeur « true ». Pour convertir une instance DB standard existante (AZ simple) vers Multi-AZ, modifiez l'instance DB dans AWS Management Console ou utilisez l'API ModifyDBInstance et définissez le paramètre Multi-AZ sur « true ».

Q : Que se passe-t-il quand je convertis mon instance RDS du Mono-AZ vers le Multi-AZ ?

Avec les moteurs de base de données RDS MySQL, MariaDB, PostgreSQL et Oracle, voici ce qui se passe quand vous décidez de convertir votre instance RDS du Mono-AZ vers le Multi-AZ :

  • Un instantané (snapshot) de votre instance principale est créé
  • Une nouvelle instance de secours est créée dans une autre zone de disponibilité (AZ) à partir de l'instantané
  • Une réplication synchronisée est configurée entre l'instance principale et l'instance de secours

Ainsi, la conversion d'une instance du Mono-AZ vers le Multi-AZ ne devrait pas provoquer de perturbations.

Q : Qu'est-ce qui peut amener Amazon RDS à lancer un basculement vers le réplica de secours ?

Pour les déploiements multi-AZ, Amazon RDS assure une détection et une récupération automatique dans la plupart des scénarios de défaillance courants afin que vous puissiez reprendre les opérations de base de données aussi rapidement que possible et sans intervention d'un administrateur. Amazon RDS procède automatiquement au basculement dès lors qu'un des événements suivants se produit :

  • Perte de disponibilité dans la zone de disponibilité principale
  • Perte de connectivité réseau avec le serveur principal
  • Échec d'unité de calcul sur le serveur principal
  • Échec de stockage sur le serveur principal

Remarque : pour une meilleure disponibilité, lorsque des opérations telles que le dimensionnement d'une instance DB ou la réalisation de mises à niveau système (application de correctifs sur le SE, par exemple) sont lancées sur des déploiements multi-AZ, elles sont d'abord appliquées au niveau de l'instance de secours avant tout basculement automatique. En conséquence, l'impact sur votre disponibilité est uniquement limité à la durée de mise en place du basculement. Notez que les déploiements multi-AZ d'Amazon RDS ne basculent pas automatiquement en cas d'opérations de bases de données telles que les requêtes à exécution prolongée, les verrous bloquants ou les erreurs d'altération de la base de données.

Q : Serai-je averti lorsqu'un basculement automatique a lieu ?

Oui, Amazon RDS émettra un événement d'instance DB vous informant qu'un basculement automatique a eu lieu. Vous pouvez cliquer sur la section « Events » d'Amazon RDS Console ou utiliser l'API DescribeEvents pour renvoyer des informations sur des événements liés à votre instance DB. Vous pouvez également utiliser la notification d'événement Amazon RDS pour être informé quand des événements DB particuliers se produisent.

Q : Que se passe-t-il au cours du basculement multi-AZ et combien de temps cela dure-t-il ?

Le basculement est automatiquement traité par Amazon RDS afin que vous puissiez reprendre vos opérations de base de données aussi vite que possible sans intervention administrative. Lors du basculement, Amazon RDS retourne simplement l'enregistrement de nom canonique (CNAME) de votre instance DB pour pointer vers l'instance de secours, qui est promue à son tour pour devenir la nouvelle instance principale. Nous vous encourageons à suivre les bonnes pratiques et à implémenter une nouvelle tentative de connexion de base de données au niveau de la couche d'application.

Les basculements, tels que définis par l'intervalle entre la détection de la défaillance dans l'instance primaire et la reprise des transactions dans l'instance de secours, s'effectuent généralement en une ou deux minutes. La durée du basculement peut également être affectée par la nécessité de restaurer de grandes transactions non validées. Il est recommandé d'utiliser des types d'instances au volume approprié avec multi-AZ pour obtenir les meilleurs résultats. AWS recommande également d'utiliser les volumes IOPS dimensionnés avec les instances multi-AZ pour obtenir des performances de débit rapides, prévisibles et homogènes.

Q : Puis-je lancer un « basculement forcé » de mon déploiement d'instance DB multi-AZ ?

Amazon RDS procède au basculement automatique, sans aucune intervention de l'utilisateur, dans diverses conditions d'échec. En outre, Amazon RDS offre une option permettant de lancer un basculement lors du redémarrage de votre instance. Vous pouvez accéder à cette fonctionnalité via AWS Management Console ou en appelant l'API RebootDBInstance.

Q : Comment contrôler/configurer une réplication multi-AZ synchrone ?

Avec les déploiements Multi-AZ, vous définissez simplement le paramètre « Multi-AZ » sur vrai. La création de l'instance de secours, de la réplication synchrone et du basculement est traitée automatiquement. Ceci signifie que vous ne pouvez pas sélectionner la zone de disponibilité lorsque votre instance de secours est déployée ou modifier le nombre d'instances de secours disponibles (Amazon RDS met en service une instance de secours dédiée par instance DB principale). Par ailleurs, le réplica de secours ne peut pas être configuré pour accepter des activités en lecture de base de données. En savoir plus sur les configurations multi-AZ.

Q : Mon instance de secours se trouvera-t-elle dans la même région que mon instance principale ?

Oui. Votre instance de secours est mise automatiquement en service dans une zone de disponibilité différente de la même région comme votre instance DB principale.

Q : Puis-je voir dans quelle zone de disponibilité mon instance principale est située actuellement ?

Oui, vous pouvez avoir accès à l'emplacement de l'instance principale actuelle en utilisant AWS Management Console ou l'API DescribeDBInstances.

Q : Après un basculement, mon instance principale se trouve désormais dans une zone de disponibilité différente de celle de mes autres ressources AWS (par ex., instances EC2). Dois-je m'inquiéter des temps de latence ?

Les zones de disponibilité sont conçues pour fournir une connectivité de réseau à faible latence vers les autres zones de disponibilité dans la même région. En outre, vous pourriez envisager d'avoir une architecture avec redondance pour votre application et d'autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d'une zone de disponibilité. Les déploiements Multi-AZ répondent à ce besoin pour le niveau de base de données sans administration de votre part.

Q : Comment les instantanés DB et les sauvegardes automatisées fonctionnent-ils avec mon déploiement multi-AZ ?

Vous interagissez avec la fonctionnalité de sauvegarde automatisée et les instantanés DB de la même manière, que vous exécutiez un déploiement standard mono-AZ ou un déploiement multi-AZ. Si vous exécutez un déploiement Multi-AZ, les sauvegardes automatisées et les instantanés DB sont simplement pris à partir de l'instance de secours, afin d'éviter la suspension d'E/S sur l'instance principale. Notez qu'il est possible de constater un temps de latence accru en E/S (généralement quelques minutes) lors des sauvegardes, à la fois pour les déploiements mono-AZ et multi-AZ.

Dans les déploiements multi-AZ, les opérations de restauration (restauration à un moment donné ou restauration à partir d'un instantané DB) fonctionnent de la même manière que dans les déploiements mono-AZ standard. Les nouveaux déploiements d'instance DB peuvent être créés avec l'API RestoreDBInstanceFromSnapshot ou RestoreDBInstanceToPointInTime. Ces nouveaux déploiements d'instance DB peuvent être standards ou multi-AZ, que la sauvegarde source ait été lancée sur un déploiement standard ou multi-AZ.

Q : Que signifie exécuter une instance DB en tant que réplica en lecture ?

Les réplicas en lecture exploitent la fonctionnalité de réplication intégrée des moteurs pris en charge afin de procéder à un dimensionnement de manière extensible au-delà des contraintes de capacités d'une seule instance DB pour les charges de travail de base de données à lecture importante. Vous pouvez créer un réplica en lecture en quelques clics sur AWS Management Console ou en utilisant l'API CreateDBInstanceReadReplica. Une fois que le réplica en lecture est créé, les mises à jour de base de données sur l'instance DB source seront répliquées en utilisant la réplication native et asynchrone du moteur pris en charge. Vous pouvez créer plusieurs réplicas en lecture pour une instance DB source donnée et répartir le trafic en lecture de votre application sur ces réplicas. Étant donné que les réplicas en lecture utilisent la réplication intégrée des moteurs pris en charge, ils exploitent ses avantages et sont soumis à ses limitations. En particulier, les mises à jour sont appliquées à votre ou vos réplicas en lecture après qu'elles ont eu lieu sur l'instance DB source et le retard de réplication peut varier de manière importante. Les réplicas en lecture peuvent être associés aux déploiements multi-AZ, afin de profiter des avantages de dimensionnement en lecture, en plus de la disponibilité en lecture de base de données et de la durabilité des données améliorées fournies par les déploiements multi-AZ.

Q : Quand envisager l'utilisation d'un réplica en lecture Amazon RDS ?

Il existe divers scénarios où le déploiement d'un ou plusieurs réplicas en lecture pour une instance DB source donnée est recommandé. Les raisons fréquentes d'un déploiement de réplica en lecture incluent :

  • Le dimensionnement au-delà de la capacité de calcul ou E/S d'une seule instance DB pour des charges de travail de bases de données à lecture importante. Ce trafic en lecture excessif peut être dirigé vers un ou plusieurs réplicas en lecture.
  • Le service du trafic en lecture alors que l'instance DB source est indisponible. Si votre instance DB source ne peut pas prendre en charge les demandes E/S (par ex. en raison de la suspension d'E/S pour les sauvegardes ou la maintenance planifiée), vous pouvez diriger le trafic en lecture vers votre/vos réplicas en lecture. Pour cette utilisation, gardez à l'esprit le fait que les données sur le réplica en lecture peuvent être « périmées » étant donné que l'instance DB source est indisponible.
  • Rapports commerciaux ou entreposage de données ; vous pouvez souhaiter que les requêtes de rapports commerciaux soient exécutées sur un réplica en lecture, plutôt que sur votre instance DB principale de production.

Q : Dois-je activer les sauvegardes automatiques sur mon instance DB avant de créer des réplicas en lecture ?

Oui. Activez les sauvegardes automatiques sur votre instance DB avant d'ajouter des réplicas en lecture, en définissant la période de rétention des sauvegardes sur une valeur autre que 0. Les sauvegardes doivent rester activées pour que les réplicas en lecture fonctionnent.

Q : Quelles versions des moteurs de base de données les réplicas en lecture Amazon RDS prennent-ils en charge ?

Amazon Aurora (MySQL) : toutes les instances de base de données.

Amazon RDS for MySQL : les instances DB dotées de MySQL 5.5 ou version ultérieure prennent en charge la création de réplicas en lecture. Les sauvegardes automatiques doivent rester activées sur l'instance DB source pour les opérations de réplicas en lecture. Les sauvegardes automatiques sont prises en charge uniquement pour les réplicas en lecture Amazon RDS exécutant MySQL 5.6 et plus, et non la version 5.5.

Amazon RDS for PostgreSQL : les instances DB dotées de PostgreSQL 9.3.5 ou version ultérieure prennent en charge la création de réplicas en lecture. Les instances PostgreSQL existantes dotées d'une version antérieure à 9.3.5 doivent être mises à niveau vers la version 9.3.5 de PostgreSQL pour exploiter les réplicas en lecture Amazon RDS.

Amazon RDS for MariaDB : les instances DB dotées de MariaDB 10.0 ou version ultérieure prennent en charge la création de réplicas en lecture. Les sauvegardes automatiques doivent rester activées sur l'instance DB source pour les opérations de réplicas en lecture.

Q : Comment déployer un réplica en lecture pour une instance DB donnée ?

Vous pouvez créer un réplica en lecture en quelques minutes au moyen de l'API CreateDBInstanceReadReplica standard ou en quelques clics dans AWS Management Console. Lorsque vous créez un réplica en lecture, vous pouvez l'identifier en tant que tel en spécifiant un identifiant SourceDBInstanceIdentifier. SourceDBInstanceIdentifier est l'identifiant d'instance DB de l'instance DB « source » à partir de laquelle vous souhaitez effectuer le réplica. Comme pour l'instance DB standard, vous pouvez également spécifier la zone de disponibilité, la classe d'instance DB et la fenêtre de maintenance préférée. La version du moteur (par ex. PostgreSQL 9.3.5) et l'attribution de stockage d'un réplica en lecture sont héritées de l'instance DB source. Lorsque vous lancez la création d'un réplica en lecture, Amazon RDS prend un instantané de votre instance DB source et commence la réplication. En conséquence, vous rencontrerez une brève suspension d'E/S sur votre instance DB source au moment où l'instantané a lieu. La suspension d'E/S dure généralement environ une minute et est évitée si l'instance DB source est un déploiement multi-AZ (dans le cas des déploiements multi-AZ, les instantanés sont pris depuis l'instance de secours). Amazon RDS travaille aussi actuellement sur une optimisation (disponible prochainement), de sorte que si vous créez plusieurs réplicas en lecture dans une fenêtre de 30 minutes, tous utiliseront le même instantané source, afin de minimiser l'impact E/S (une réplication de « rattrapage » pour chaque réplica en lecture démarrera après la création).

Q : Comment me connecter à mes réplicas en lecture ?

Vous pouvez vous connecter à un réplica en lecture de la même manière qu'à une instance DB standard, en utilisant l'API DescribeDBInstance ou AWS Management Console pour récupérer votre/vos points de terminaison vers votre/vos réplicas en lecture. Si vous avez plusieurs réplicas en lecture, c'est votre application qui détermine comment le trafic en lecture sera distribué parmi eux.

Q : Combien de réplicas en lecture puis-je créer pour une instance DB source donnée ?

Amazon Aurora (MySQL) permet de créer jusqu'à 15 réplicas en lecture pour une même instance de base de données source.

A l'heure actuelle, Amazon RDS for MySQL, MariaDB et PostgreSQL vous permettent de créer jusqu'à 5 réplicas en lecture pour une même instance de base de données source.

Q : Puis-je créer un réplica en lecture dans une région AWS différente de celle de l'instance de base de données source ?

Oui, RDS prend en charge les réplicas en lecture entre régions.

Q : Les réplicas en lecture Amazon RDS prennent-ils en charge la réplication synchrone ?

Non. Les réplicas en lecture dans Amazon RDS for MySQL, MariaDB et PostgreSQL sont créés à l'aide de la réplication asynchrone native de ces moteurs. Amazon Aurora utilise un autre mécanisme de réplication asynchrone.

Q : Puis-je utiliser un réplica en lecture pour améliorer la disponibilité en écriture de la base de données ou protéger les données sur mon instance DB source contre les défaillances ?

Si vous cherchez à utiliser la réplication pour augmenter la disponibilité en écriture de la base de données et protéger les mises à jour de base de données récentes contre diverses possibilités de défaillance, nous vous recommandons d'exécuter votre instance DB en tant que déploiement Multi-AZ. Avec les réplicas en lecture Amazon RDS, qui ont recours à la réplication asynchrone native des moteurs pris en charge, les écritures de base de données se produisent sur un réplica en lecture après qu'elles se sont déjà produites sur l'instance DB source, et ce « retard » de réplication peut considérablement varier. Au contraire, la réplication utilisée par les déploiements Multi-AZ est synchrone, ce qui signifie que toutes les écritures de base de données sont simultanées sur les instances principales et de secours. Ceci protège vos dernières mises à jour de base de données, car elles doivent être disponibles sur l'instance de secours au cas où un basculement serait nécessaire. En outre, avec les déploiements Multi-AZ, la réplication est totalement gérée. Amazon RDS détecte automatiquement les dysfonctionnements des instances de base de données et des zones de disponibilité et exécute un basculement automatique vers l'instance de secours (ou, pour Amazon Aurora, vers un réplica en lecture) en cas de panne.

Q : Puis-je créer un réplica en lecture avec un déploiement d'instance DB multi-AZ comme source ?

Oui. Comme les instances DB Multi-AZ répondent à un besoin différent de celui des réplicas en lecture, il est logique d'utiliser les deux conjointement pour les déploiements de production et d'associer un réplica en lecture avec un déploiement d'instance DB Multi-AZ. L'instance DB Multi AZ « source » fournit une disponibilité en écriture et une durabilité des données améliorées et le réplica en lecture associé améliore le dimensionnement du trafic en lecture.

Q : Mes réplicas en lecture Amazon RDS peuvent-ils eux aussi passer en multi-AZ ?

Amazon RDS for MySQL, MariaDB et PostgreSQL ne prend pas actuellement en charge cette fonction.

Q : Si mes réplicas en lecture utilisent un déploiement d'instance DB multi-AZ en tant que source, que se passe-t-il si un basculement multi-AZ a lieu ?

En cas de basculement Multi-AZ, tout réplica en lecture associé et disponible doit reprendre la réplication automatique une fois le basculement terminé (acquisition des mises à jour depuis l'instance qui vient de devenir principale).

Q : Puis-je créer un réplica en lecture d'un autre réplica en lecture ?

Amazon Aurora, Amazon RDS for MySQL et MariaDB : vous pouvez créer un réplica en lecture de second niveau à partir d'un réplica en lecture de premier niveau existant. En créant un réplica en lecture de second niveau, vous pouvez transférer une partie de la charge de réplication de l'instance de base de données principale vers un réplica en lecture de premier niveau. Il se peut que le réplica de lecture de second niveau présente un délai d'actualisation plus long par rapport à l'instance principale, car cette réplication implique un temps de latence supplémentaire dans la mesure où les transactions sont d'abord répliquées de l'instance principale vers le réplica de premier niveau, puis de celui-ci vers le réplica de second niveau.

Amazon RDS pour PostgreSQL : les réplicas en lecture créés à partir de réplicas en lecture ne sont pas actuellement pris en charge.

Q : Mes réplicas en lecture peuvent-ils uniquement accepter les opérations de base de données en lecture ?

Les réplicas en lecture sont conçus pour servir le trafic en lecture. Toutefois, il peut y avoir des cas d'application où les utilisateurs avancés souhaitent remplir des déclarations SQL de langage de définition des données (Data Definition Language – DDL) par rapport à un réplica en lecture. Les exemples peuvent inclure l'ajout d'un index de base de données vers un réplica en lecture utilisé pour les rapports commerciaux, sans l'ajout du même index à l'instance DB source correspondante.

Amazon RDS pour MySQL peut être configuré de sorte qu'il permette les déclarations SQL de langage de définition des données par rapport à un réplica en lecture. Si vous souhaitez activer des opérations autres que celles en lecture pour un réplica en lecture donné, vous devez modifier le groupe de paramètres DB actif pour le réplica en lecture, en définissant le paramètre « read_only » sur « 0 ».

Amazon RDS pour PostgreSQL ne prend pas actuellement en charge l'exécution de déclarations SQL de langage de définition des données par rapport à un réplica en lecture.

Q : Puis-je transformer mon réplica en lecture en instance DB « autonome » ?

Oui. Pour en savoir plus, consultez le manuel Amazon RDS User Guide.

Q : Mon réplica en lecture sera-t-il tenu à jour par rapport à l'instance DB source ?

Les mises à jour vers une instance DB source seront immédiatement répliquées vers tous les réplicas en lecture associés. Toutefois, avec la technologie de réplication asynchrone des moteurs pris en charge, un réplica en lecture peut prendre du retard par rapport à son instance DB source pour diverses raisons. Les raisons typiques incluent :

  • Le volume d'écriture E/S vers l'instance DB source dépasse la vitesse à laquelle les modifications peuvent être appliquées au réplica en lecture (ce problème est particulièrement susceptible de se présenter si la capacité d'un réplica en lecture est inférieure à l'instance DB source)
  • Les transactions complexes ou longues vers l'instance DB source retardent la réplication vers le réplica en lecture
  • Des partitions ou de la latence réseau entre l'instance DB source et un réplica en lecture

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication native des moteurs pris en charge. Si vous utilisez des réplicas en lecture, vous devez être conscient du potentiel de retard entre un réplica en lecture et son instance DB source ou d'une « incohérence ». Cliquez ici pour des recommandations au cas où votre/vos réplicas en lecture prennent du retard par rapport à leurs sources.

Q : Comment puis-je consulter l'état de mes réplicas en lecture actifs ?

Vous pouvez utiliser l'API DescribeDBInstances standard pour renvoyer une liste de toutes les instances DB que vous avez déployées (y compris les réplicas en lecture), ou cliquez simplement sur l'onglet « Instances DB » de la console Amazon RDS.

Amazon RDS vous permet de voir à quel point un réplica en lecture a pris du retard par rapport à son instance DB source. Le nombre de secondes de retard du réplica en lecture par rapport à l'instance de base est publié sous la forme d'une mesure Amazon CloudWatch (« Replica Lag ») accessible via AWS Management Console ou les API Amazon CloudWatch. Pour Amazon RDS pour MySQL, la source de cette information est similaire à celle affichée en émettant une commande MySQL « Show Slave Status » standard pour le réplica en lecture. Pour Amazon RDS pour PostgreSQL, vous pouvez utiliser l'affichage pg_stat_replication sur l'instance DB source pour découvrir les mesures de réplication.

Amazon RDS surveille le statut de réplication de vos réplicas en lecture et met à jour le champ Replication State sur Error dans AWS Management Console si la réplication est interrompue pour une raison quelconque (par exemple, l'exécution sur votre réplica de requêtes DML incompatibles avec les mises à jour effectuées sur l'instance de base de données principale peut occasionner une erreur de réplication). Vous pouvez consulter les détails de l'erreur en question, signalée par le moteur MySQL, dans le champ Replication Error, et ainsi effectuer l'opération de récupération appropriée. Pour en savoir plus sur le dépannage des problèmes de réplications, consultez la section Troubleshooting a Read Replica Problem du manuel User Guide d'Amazon RDS pour MySQL ou PostgreSQL.

Lorsqu'une erreur de réplication est résolue, le champ Replication State présente la valeur Replicating.

Q : Mon réplica en lecture a pris beaucoup de retard par rapport à son instance DB source. Que dois-je faire ?

Comme abordé dans les questions précédentes, l'« incohérence » ou l'écart entre un réplica en lecture et son instance DB source est courant avec la réplication asynchrone. Si un réplica en lecture existant a pris trop de retard pour répondre à vos besoins, vous pouvez le supprimer et en créer un nouveau avec le même point de terminaison au moyen des mêmes identifiants d'instance DB et d'instance DB source que les réplicas en lecture supprimés. Gardez à l'esprit le fait que les processus de recréation seront contre-productifs en cas de niveau de décalage faible (par ex. moins de cinq minutes de décalage) et ne doivent être utilisés qu'avec prudence (c.-à-d. uniquement lorsque le réplica en lecture est considérablement derrière son instance DB source). Gardez également à l'esprit le fait que le retard du réplica peut augmenter et diminuer naturellement avec le temps, en fonction du modèle d'utilisation continue de votre instance DB source.

Dimensionner la classe d'instance DB d'un réplica en lecture peut réduire le retard de réplication dans certains cas, en particulier si votre classe d'instance DB source est plus importante que votre classe d'instance DB de réplica en lecture. Toutefois, il n'est pas garanti que les réplicas en lecture fonctionnent dans tous les cas. Il peut y avoir des scénarios et des modèles d'utilisation où un réplica en lecture ne peut jamais rattraper sa source après la création initiale ou qu'il reste trop loin de sa source pour répondre aux besoins de votre cas d'application.

Q : J'ai dimensionné les capacités de calcul et/ou de stockage de mon instance DB source. Dois-je également dimensionner les ressources pour les réplicas en lecture associés ?

Pour que la réplication fonctionne efficacement, nous recommandons que les réplicas en lecture disposent d'autant ou de plus de ressources de calcul et de stockage que leurs instances DB sources respectives. Autrement, il est probable que le retard de réplication augmentera ou que votre réplica en lecture pourrait ne plus avoir d'espace pour stocker les mises à jour répliquées.

Q : Les instantanés DB ou sauvegardes automatisées peuvent-ils être réalisés à partir de réplicas en lecture ?

Non. Si vous cherchez à augmenter la disponibilité en écriture de la base de données en prenant des sauvegardes depuis votre réplica en lecture plutôt que de son instance DB source, vous pouvez réaliser le même objectif en exécutant votre instance DB en tant que déploiement Multi-AZ. Les sauvegardes seront ensuite lancées depuis l'instance de secours Multi-AZ afin de minimiser l'impact sur la disponibilité.

Q : Comment supprimer un réplica en lecture ? Le réplica sera-t-il automatiquement supprimé si son instance DB source est supprimée ?

Vous pouvez facilement supprimer un réplica en lecture en quelques clics sur AWS Management Console ou en passant son identifiant d'instance DB vers l'API DeleteDBInstance.

Un réplica en lecture Amazon Aurora (MySQL) reste actif et continue d'accepter le trafic en lecture, même après la suppression de l'instance de base de données source correspondante. Un des réplicas en lecture dans le cluster est automatiquement défini comme la nouvelle instance principale et commence à accepter le trafic en écriture.

Un réplica en lecture Amazon RDS for MySQL ou MariaDB restera actif et continuera d'accepter le trafic en lecture même après que son instance DB source correspondante a été supprimée. Si vous souhaitez supprimer le réplica en lecture en plus de l'instance DB source, vous devez le faire explicitement au moyen de l'API DeleteDBInstance ou d'AWS Management Console.

Si vous supprimez une instance DB Amazon RDS pour PostgreSQL qui dispose de réplicas en lecture, tous les réplicas en lecture seront promus vers les instances DB autonomes et seront en mesure d'accepter le trafic en lecture et celui en écriture. Les instances DB nouvellement promues fonctionneront indépendamment les unes des autres. Si vous souhaitez supprimer ces instances DB en plus de l'instance DB source, vous devez le faire explicitement au moyen de l'API DeleteDBInstance ou d'AWS Management Console.

Q : Puis-je accéder directement aux journaux d'événements de mon instance de base de données ?

Avec Amazon RDS for MySQL ou Amazon RDS for MariaDB, vous pouvez utiliser l'utilitaire mysqlbinlog pour télécharger ou diffuser des journaux binaires à partir de votre instance DB. Amazon RDS pour PostgreSQL ne fournit actuellement pas d'accès aux fichiers WAL pour votre instance DB.

Q : Combien coûtent les réplicas en lecture ? Quelles sont les dates de début et de fin de facturation ?

Un réplica en lecture est facturé comme une instance DB standard et aux mêmes tarifs. Pour plus d'informations sur la facturation des instances DB, consultez cette FAQ. Comme pour une instance DB standard, le tarif par « heure d'instance DB » pour un réplica en lecture est déterminé par sa classe d'instance, consultez la page de détails Amazon RDS pour la tarification à jour. Les frais de transfert de données lors de la réplication des données entre votre instance DB source et le réplica en lecture ne vous seront pas facturés.

La facturation du réplica en lecture débute dès sa création (c.-à-d. lorsque le statut indiqué est « active »). Le réplica en lecture continuera d'être facturé aux tarifs horaires d'instance de base de données standard d'Amazon RDS jusqu'à ce que vous émettiez une commande pour le supprimer.

Q : Dans quelle mesure la prise en charge des réplicas en lecture varie-t-elle entre les moteurs Amazon RDS qui prennent en charge cette fonctionnalité ?

Les réplicas en lecture dans Amazon RDS for PostgreSQL, MySQL et MariaDB vous permettent de procéder à un dimensionnement de façon extensible au-delà des contraintes de capacité d'une seule instance DB pour les charges de travail de base de données à lecture intensive. Il existe des similarités et des différences dans l'implémentation, car ils exploitent les fonctionnalités natives des moteurs. Consultez le tableau suivant pour plus d'informations.

Fonctionnalité PostgreSQL MySQL MariaDB
Nombre maximal autorisé de réplicas en lecture par instance DB source
5 5 5
Méthode de réplication Asynchrone
Physique
Asynchrone
Logique
Asynchrone
Logique
Les sauvegardes automatiques doivent-elles être activées pour la prise en charge des réplicas en lecture ? Oui Oui Oui
Versions des moteurs pour lesquelles les réplicas en lecture sont disponibles 9.3.5 ou version ultérieure 5.5 ou version ultérieure 10.0 ou version ultérieure
Promotion des réplicas en lecture vers une nouvelle instance DB autonome Pris en charge Pris en charge Pris en charge
Création d'index pour les réplicas en lecture Actuellement non pris en charge Pris en charge Pris en charge
Création de sauvegardes des réplicas en lecture Actuellement non pris en charge Pris en charge Pris en charge
Chaînage de réplicas en lecture
(par ex. des réplicas en lecture créés à partir de réplicas en lecture)
Actuellement non pris en charge Pris en charge Pris en charge
Réplicas en lecture entre régions Pris en charge Pris en charge Pris en charge

Q : Qu'est-ce qu'Enhanced Monitoring pour RDS ?

Enhanced Monitoring pour RDS vous permet de suivre plus précisément l'état de vos instances RDS. Pour en profiter, activez l'option Enhanced Monitoring pour votre instance DB RDS et indiquez une granularité. Enhanced Monitoring se chargera alors de collecter des données sur les métriques les plus importantes du système d'exploitation et sur les informations de processus à la granularité définie.

Q : Quels processus et métriques puis-je surveiller avec Enhanced Monitoring ?

Enhanced Monitoring capture les métriques du système de votre instance RDS, comme le CPU, la mémoire, le système de fichiers et les entrées/sorties de disque. La liste complète des métriques suivies est accessible ici.

Q : Quels sont les moteurs pris en charge par Enhanced Monitoring ?

Enhanced Monitoring prend en charge tous les moteurs de base de données RDS.

Q : Quels sont les types d'instance pris en charge par Enhanced Monitoring ?

Enhanced Monitoring prend en charge tous les types d'instance, sauf t1.micro et m1.small. Ce logiciel utilise peu de ressources CPU, mémoire et E/S. Pour les applications de surveillance génériques, nous conseillons d'utiliser des granularités élevées sur les instances de taille medium ou plus. Pour les instances DB hors production, la fonctionnalité Enhanced Monitoring est désactivée par défaut, et vous avez la possibilité de la laisser dans cet état ou d'en modifier la granularité pendant son activation.

Q : Quelles informations puis-je consulter sur le tableau de bord RDS ?

Vous pouvez afficher toutes les métriques système et informations de processus de vos instances DB RDS sous forme graphique sur la console. Il est possible de gérer les métriques à surveiller pour chaque instance et de personnaliser le tableau de bord en fonction des besoins.

Q : Les métriques de toutes les instances de mon compte RDS seront-elles suivies avec la même granularité ?

Non. Vous pouvez configurer différentes granularités pour chaque instance DB dans votre compte RDS. Vous pouvez également choisir les instances pour lesquelles vous désirez activer Enhanced Monitoring, et modifier la granularité de n'importe quelle instance à tout moment.

Q : Jusqu'à quand s'étend l'historique des métriques dans la console RDS ?

Vous pouvez afficher les valeurs de performance de toutes les métriques jusqu'à 1 heure dans le passé, avec une granularité pouvant atteindre 1 seconde en fonction de votre configuration.

Q : Comment puis-je visualiser les métriques générées par RDS Enhanced Monitoring dans CloudWatch ?

Les métriques de RDS Enhanced Monitoring sont envoyées à votre compte CloudWatch Logs. Vous pouvez créer des filtres de métrique dans CloudWatch à partir de CloudWatch Logs et afficher les graphiques sur le tableau de bord CloudWatch. Pour plus d'informations, consultez la page Amazon CloudWatch.

Q : Quand dois-je utiliser CloudWatch au lieu du tableau de bord de la console RDS ?

Il est conseillé d'utiliser CloudWatch si vous désirez consulter un historique de données plus étendu que ce que propose le tableau de bord de la console RDS. Vous pouvez surveiller vos instances RDS dans CloudWatch pour vérifier l'état de votre stack AWS tout entier depuis le même endroit. A l'heure actuelle, CloudWatch prend en charge des granularités pouvant atteindre 1 minute, et la moyenne des valeurs sera affichée pour les granularités inférieures.

Q : Puis-je mettre en place des alarmes et des notifications à partir de certaines métriques ?

Oui. Vous pouvez créer une alarme dans CloudWatch et envoyer une notification quand elle change d'état. Cette alarme surveille une métrique unique pendant une période que vous définissez, et réalise une ou plusieurs actions selon la valeur de la métrique par rapport au seuil défini sur différentes périodes. Pour plus d'informations sur les alarmes CloudWatch, veuillez consulter le manuel Amazon CloudWatch Developer Guide.

Q : Comment puis-je intégrer Enhanced Monitoring à l'outil que j'utilise ?

RDS Enhanced Monitoring présente un ensemble de métriques sous la forme d'unités de charge JSON envoyées à votre compte CloudWatch Logs. Les unités de charge JSON sont envoyées à la granularité dernièrement définie pour l'instance RDS.

Vous pouvez consulter les métriques à l'aide d'une application ou d'un tableau de bord tiers de différentes façons. Les outils de surveillance ont la possibilité d'utiliser un abonnement à CloudWatch Logs pour mettre en place un flux de métriques en quasi-temps réel. Vous pouvez aussi utiliser des filtres dans CloudWatch Logs pour transférer les métriques à CloudWatch et intégrer votre application à CloudWatch. Consultez la page Documentation Amazon CloudWatch pour en savoir plus.

Q : Comment puis-je supprimer l'historique de données ?

Etant donné qu'Enhanced Monitoring envoie des unités de charge JSON à un journal dans votre compte CloudWatch Logs, vous pouvez en contrôler la période de rétention comme n'importe quel autre flux CloudWatch Logs. La période de rétention par défaut d'Enhanced Monitoring dans CloudWatch Logs est de 30 jours. Pour apprendre à modifier les paramètres de rétention, consultez le manuel Amazon CloudWatch Developer Guide.

Q : Quel impact la fonctionnalité Enhanced Monitoring aura-t-elle sur mes factures mensuelles ?

Puisque les métriques sont envoyées à CloudWatch Logs, vos frais seront basés sur les tarifs de stockage et de transfert de données de CloudWatch Logs une fois l'offre gratuite dépassée. Pour connaître les informations de tarification, cliquez ici. La quantité d'informations transférée pour une instance RDS est directement proportionnelle à la granularité définie pour la fonctionnalité Enhanced Monitoring. Les administrateurs peuvent configurer différentes granularités pour chaque instance de leur compte pour limiter les frais.

Le volume approximatif de données envoyées à CloudWatch Logs par Enhanced Monitoring pour une instance donnée est indiqué ci-dessous :

Granularité

60 secondes

30 secondes

15 secondes

10 secondes

5 secondes

1 seconde

Données envoyées à CloudWatch Logs* (Go par mois)

0,27

0,53

1,07

1,61

3,21

16,07