Amazon Relational Database Service
Guide de l'utilisateur

Bonnes pratiques pour Amazon RDS

Découvrez les bonnes pratiques d'utilisation de Amazon RDS. A mesure que de nouvelles bonnes pratiques seront identifiées, nous mettrons à jour cette section.

Note

Pour obtenir des recommandations communes pour Amazon RDS, consultez Utilisation des recommandations Amazon RDS.

Directives opérationnelles de base Amazon RDS

Voici les directives opérationnelles de base que toute personne doit suivre lorsqu'elle utilise Amazon RDS. Notez que le contrat de niveau de service (SLA) Amazon RDS exige que vous suiviez ces directives :

  • Surveillez l'utilisation de votre mémoire, de votre UC et de votre espace de stockage. Amazon CloudWatch peut être configuré pour vous informer quand vos habitudes d'utilisation changent ou quand vous atteignez le maximum votre capacité de développement, afin que vous puissiez maintenir les performances et la disponibilité du système.

  • Augmentez la capacité de votre instance de base de données lorsque vous atteignez la limite de stockage. Vous devrez disposer de capacités de mémoire et de stockage supplémentaires pour vous adapter aux hausses imprévues des besoins de vos applications.

  • Activez les sauvegardes automatiques et configurez-les pour qu'elles s'exécutent pendant la plus faible I/O par seconde en écriture de la journée.

  • Si la charge de travail de votre base de données exige plus d'I/O que vous avez provisionné, la récupération suite à un basculement ou un échec de la base de données est lente. Pour augmenter la capacité d'I/O d'une instance de base de données, procédez comme suit :

    • Migrez vers une classe d'instance de base de données avec une forte capacité d'I/O.

    • Passez du stockage standard au stockage à usage général ou au stockage à IOPS provisionnées, suivant l'augmentation dont vous avez besoin. Pour plus d'informations sur les types de stockage disponibles, consultez Types de stockage Amazon RDS.

      Si vous passez au stockage à IOPS provisionnées, veillez que vous utilisez également une classe d'instance de base de données optimisée pour les IOPS provisionnées. Pour plus d'informations sur les IOPS provisionnées, consultez Stockage SSD d'I/O par seconde provisionnées.

    • Si vous utilisez déjà un stockage d'IOPS provisionnées, allouez un débit supplémentaire.

  • Si votre application cliente met en cache les données DNS (Domain Name Service) de vos instances de base de données, définissez une valeur durée de vie (TTL) de moins de 30 secondes. Étant donné que l'adresse IP sous-jacente d'une instance de base de données peut changer suite à un basculement, la mise en cache des données DNS pour une durée prolongée peut entraîner des échecs de connexion si votre application tente de se connecter à une adresse IP qui n'est plus en service.

  • Testez le basculement pour votre instance de base de données afin de connaître la durée du processus pour votre cas d'utilisation et veiller à ce que l'application qui accède à votre instance de base de données puisse automatiquement se connecter à la nouvelle instance de base de données suite au basculement.

Recommandations RAM d'une instance de base de données

Une bonne pratique Amazon RDS en matière de performances consiste à attribuer suffisamment de RAM pour que votre ensemble de travail réside presque totalement en mémoire. Pour savoir si votre ensemble de travail est presque totalement en mémoire, vérifiez les métriques d'I/O par seconde en lecture (avec Amazon CloudWatch) pendant que l'instance de base de données est en chargement. La valeur d'I/O par seconde en lecture doit être faible et stable. Si l'augmentation de la classe d'instance de base de données—pour une classe avec plus de RAM—entraîne une chute spectaculaire de ReadIOPS, cela signifie que votre ensemble de travail n'était pas encore totalement en mémoire. Continuez à augmenter jusqu'à ce que la valeur d'I/O par seconde en lecture ne chute plus de façon spectaculaire suite à une opération de dimensionnement, ou qu'elle soit réduite au minimum. Pour plus d'informations sur la supervision des métriques d'une instance de base de données, consultez Affichage des métriques d'instances de base de données.

Utilisation de la surveillance améliorée pour identifier les problèmes de système d'exploitation

Amazon RDS fournit des métriques en temps réel pour le système d'exploitation sur lequel votre instance de base de données s'exécute. Vous pouvez afficher les métriques pour votre instance de base de données à l'aide de la console, ou utiliser la sortie JSON de surveillance améliorée d'Amazon CloudWatch Logs dans le système de surveillance de votre choix. Pour plus d'informations sur la surveillance améliorée, consultez Surveillance améliorée

La surveillance améliorée est disponible pour les moteurs de base de données suivants :

  • MariaDB

  • Microsoft SQL Server

  • MySQL version 5.5 ou version ultérieure

  • Oracle

  • PostgreSQL

La surveillance améliorée est disponible pour toutes les classes d'instances de bases de données, à l'exception de db.m1.small. La surveillance améliorée est disponible dans toutes les régions, à l'exception de AWS GovCloud (US-West).

Utilisation des métriques pour identifier les problèmes de performances

Pour identifier les problèmes de performances causés par des ressources insuffisantes et d'autres goulots d'étranglement courants, vous pouvez surveiller les métriques disponibles pour votre instance de base de données Amazon RDS.

Consultation des métriques de performances

Vous devez régulièrement surveiller les métriques de performances pour observer les valeurs moyennes, maximum et minimum pour différents intervalles de temps. De cette façon, vous pouvez identifier quand les performances se dégradent. Vous pouvez également configurer des alarmes Amazon CloudWatch pour des seuils de métriques spécifiques, afin d'être alerté lorsqu'ils sont atteints.

Afin de résoudre les problèmes de performances, il est important de comprendre les performances de base du système. Lorsque vous configurez une nouvelle instance de base de données et l'exécutez avec une charge de travail typique, vous devez capturer les valeurs moyennes, maximum et minimum de toutes les métriques de performances à un nombre d'intervalles différents (par exemple, une heure, 24 heures, une semaine, deux semaines) pour vous faire une idée. Cela permet de comparer l'activité pendant les heures pleines et les heures creuses. Vous pouvez ensuite utiliser ces informations pour identifier quand les performances chutent sous les niveaux standard.

Pour consulter les métriques de performances

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

  2. Dans le panneau de navigation, sélectionnez Bases de données, choisissez une instance de base de données.

  3. Choisissez Surveillance. Les huit premières métriques de performances s'affichent. Les métriques affichent par défaut les informations pour le jour même.

  4. Utilisez les boutons numérotés en haut à droite pour parcourir les autres métriques, ou choisissez Adjust the settings (Ajuster les paramètres) pour consulter d'autres métriques.

  5. Choisissez une métrique de performances pour régler l'intervalle de temps afin de consulter d'autres données que celles du jour même. Vous pouvez changer les valeurs Statistic (Statistique), Time Range (Plage de temps) et Period (Période) pour régler les informations affichées. Par exemple, pour consulter les valeurs maximales d'une métrique pour chaque jour des deux dernières semaines, configurez Statistic (Statistique) sur Maximum, Time Range (Plage de temps) sur Last 2 Weeks (Dernières 2 semaines) et Period (Période) sur Day (Jour).

    Note

    Si vous changez les valeurs Statistic (Statistique), Time Range (Plage de temps) et Period (Période), elles seront modifiées pour toutes les métriques. Les valeurs mises à jour restent inchangées tout au long de votre session ou jusqu'à ce que vous les modifiiez de nouveau.

Vous pouvez également consulter les métriques de performances à l'aide de l'interface de ligne de commande ou de l'API. Pour plus d'informations, consultez Affichage des métriques d'instances de base de données.

Pour définir une alarme CloudWatch

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

  2. Dans le panneau de navigation, sélectionnez Bases de données, choisissez une instance de base de données.

  3. Choisissez Logs & events (Journaux et événements).

  4. Dans la section Alarmes CloudWatch, choisissez Créer une alarme.

    
                            Boîte de dialogue Créer alarme
  5. Pour Envoyer des notifications, choisissez Oui et pour Envoyer des notifications à, choisissez New email or SMS topic (Nouvel e-mail ou nouvelle rubrique SMS).

  6. Dans Nom de la rubrique, entrez un nom pour la notification, et pour Avec ces destinataires, entrez une liste séparée par des virgules d'adresses e-mail et de numéros de téléphone.

  7. Pour Métrique, choisissez la statistique et la métrique d'alarme à définir.

  8. Pour Seuil, indiquez si la métrique doit être supérieure, inférieure ou égale au seuil, et définissez la valeur du seuil.

  9. Pour Période d'évaluation, choisissez la période d'évaluation de l'alarme et pour période(s) consécutive(s) de, choisissez la durée pendant laquelle le seuil doit avoir été atteint pour déclencher l'alarme.

  10. Pour Name of alarm (Nom de l'alarme), entrez un nom pour l'alarme.

  11. Sélectionnez Create Alarm.

L'alarme apparaît dans la section Alarmes CloudWatch.

Evaluation des métriques de performances

Une instance de base de données possède un nombre de catégories différentes de métriques, et la manière de déterminer les valeurs acceptables dépend de la métrique.

Processeur

  • Utilisation du processeur : pourcentage de capacité de traitement informatique utilisée.

Mémoire

  • Mémoire libérable : combien de RAM est disponible sur l'instance de base de données, en octets. La ligne rouge des métriques de l'onglet Monitoring est marqué à 75 % pour les métriques d'UC, de mémoire et de stockage. Si la consommation de la mémoire de l'instance franchit régulièrement cette ligne, cela indique que vous devez vérifier votre charge de travail ou mettre à niveau votre instance.

  • Usage du swap : combien d'espace de swap est utilisé par l'instance de base de données, en octets.

Espace disque

  • Espace de stockage libre : combien d'espace disque n'est pas utilisé actuellement par l'instance de base de données, en octets.

Opérations d'entrée/sortie

  • I/O par seconde en lecture, I/O par seconde en écriture : le nombre moyen d'opérations de lecture ou d'écriture sur disque par seconde.

  • Latence de lecture, latence d'écriture : la durée moyenne d'une opération de lecture ou d'écriture en millisecondes.

  • Débit de lecture, débit d'écriture : le nombre moyen d'octets lus depuis un disque ou écrits sur un disque par seconde.

  • Longueur de la file d'attente : le nombre d'opérations d'I/O qui attendent d'être écrites sur un disque ou lues depuis un disque.

Trafic réseau

  • Débit réseau reçu, débit réseau transmis : la vitesse du trafic réseau vers et depuis l'instance de base de données en octets par seconde.

Connexions de la base de données

  • Connexions DB : le nombre de sessions client qui sont connectées à l'instance de base de données.

Pour des descriptions individuelles plus détaillées des mesures de performances disponibles, consultez Dimensions et métriques Amazon RDS.

En général, les valeurs acceptables pour les métriques de performances dépendent de vos données de référence et de l'activité de votre application. Enquêtez sur les écarts cohérents ou tendanciels de vos données de référence. Voici quelques conseils sur les types spécifiques de métriques :

  • Forte utilisation du processeur et de la RAM : des valeurs importantes de l'utilisation du processeur et de la RAM peuvent être appropriées, pourvu qu'elles soient attendues et conformes aux objectifs pour votre application (comme le débit ou la simultanéité).

  • Utilisation de l'espace disque : enquêtez sur l'utilisation de l'espace disque si l'espace utilisé est constamment égal ou supérieur à 85 pour cent de l'espace disque total. Voyez s'il est possible de supprimer des données de l'instance ou d'archiver des données sur un système différent pour libérer de l'espace.

  • Trafic réseau : pour le trafic réseau, discutez avec votre administrateur pour connaître le débit attendu pour votre domaine réseau et votre connexion Internet. Enquêtez sur le trafic réseau si le débit est constamment inférieur à vos attentes.

  • Connexions de la base de données : envisagez de limiter les connexions de la base de données si vous constatez un nombre important de connexions utilisateur conjointement avec une baisse des performances de l'instance et des temps de réponse. Le bon nombre de connexions utilisateur pour votre instance de base de données dépendra de votre classe d'instance et de la complexité des opérations exécutées. Vous pouvez déterminer le nombre de connexions de la base de données en associant votre instance de base de données à un groupe de paramètres dans lequel le paramètre Connexions utilisateur est configuré sur un autre chiffre que 0 (illimité). Vous pouvez utiliser un groupe de paramètres existant ou en créer un nouveau. Pour plus d'informations, consultez Utilisation de groupes de paramètres de base de données.

  • Métriques IOPS : les valeurs attendues pour les métriques d'I/O par seconde dépendent de la spécification du disque et de la configuration du serveur, donc utilisez vos données de référence pour connaître les caractéristiques typiques. Enquêtez si les valeurs sont constamment différentes de vos données de référence. Pour de meilleures performances d'I/O par seconde, veillez à ce que votre ensemble de travail typique puisse être chargé en mémoire pour minimiser les opérations de lecture et écriture.

Si vous rencontrez des problèmes avec les métriques de performances, l'une des premières choses à faire pour améliorer les choses est de régler les requêtes les plus utilisées et onéreuses pour réduire la pression exercée sur les ressources système. Pour plus d'informations, consultez Réglage des requêtes

Si vos requêtes sont réglées et que le problème persiste, envisagez de mettre à jour votre Amazon RDS Choix de la classe d'instance de base de données vers une classe contenant plus de ressources (processeur, RAM, espace disque, bande passante réseau, capacité d'I/O) qui sont liées au problème que vous rencontrez.

Réglage des requêtes

L'un des meilleurs moyens d'améliorer les performances d'une instance de base de données est de régler les requêtes les plus communément utilisées et exigeantes en ressources pour les rendre moins onéreuses à exécuter.

Réglage des requêtes MySQL

Consultez Optimizing SELECT Statements (Optimisation des déclarations SELECT) dans la documentation MySQL pour plus d'informations sur l'écriture des requêtes afin d'améliorer les performances. Vous pouvez également consulter MySQL Performance Tuning and Optimization Resources (Ressources d'optimisation et de réglage de performance MySQL) pour des ressources supplémentaires de réglage des requêtes.

Réglage des requêtes Oracle

Consultez Database SQL Tuning Guide (Guide de réglage Database SQL) dans la documentation Oracle pour plus d'informations sur l'écriture et l'analyse des requêtes afin d'améliorer les performances.

Réglage des requêtes SQL Server

Consultez Analyzing a Query (Analyse d'une requête) dans la documentation SQL Server afin d'améliorer les requêtes pour les instances de base de données SQL Server. Vous pouvez également utiliser les vues de gestion dynamique (DMV) liées à l'exécution, l'index et aux I/O décrites dans la documentation Dynamic Management Views and Functions (Fonctions et vues de gestion dynamique) pour résoudre vos problèmes de requêtes SQL Server.

Un aspect courant du réglage de requête est la création d'index efficaces. Vous pouvez utiliser Assistant de réglage du moteur de base de données afin d'obtenir des améliorations potentielles d'index pour votre instance de base de données. Pour plus d'informations, consultez Analyse de la charge de travail d'une base de données sur une instance de base de données Amazon RDS avec l'Assistant Paramétrage SQL Server.

Réglage des requêtes PostgreSQL

Consultez Using EXPLAIN (Utilisation de EXPLAIN) dans la documentation PostgreSQL pour savoir comment analyser un plan de requête. Vous pouvez utiliser ces informations pour modifier une requête ou des tables sous-jacentes afin d'améliorer les performances des requêtes. Vous pouvez également consulter Controlling the Planner with Explicit JOIN Clauses (Contrôler le planificateur avec des clauses JOIN explicites) pour obtenir des astuces sur la façon dont vous pouvez spécifier des jointures dans votre requête afin d'améliorer les performances.

Réglage des requêtes MariaDB

Consultez Query Optimizations (Optimisations de requêtes) dans la documentation MariaDB pour plus d'informations sur l'écriture des requêtes afin d'améliorer les performances.

Bonnes pratiques pour utiliser les moteurs de stockage MySQL

Sur une instance de base de données MySQL, observez les limites de création de table suivantes :

  • Vous êtes limité à 10 000 tables si vous utilisez un stockage sur volumes d'IOPS provisionnées ou un stockage à usage général et que l'instance de base de données a une taille de 200 Gio ou plus.

  • Vous êtes limité à 1 000 tables si vous utilisez un stockage standard ou un stockage à usage général et que l'instance de base de données a une taille inférieure à 200 Gio.

Nous vous recommandons ces limites, car la quantité des tables augmente de façon significative le temps de récupération après un basculement ou une défaillance de la base de données. Si vous avez besoin de créer plus de tables que le nombre recommandé, configurez le paramètre innodb_file_per_table sur 0. Pour plus d'informations, consultez Utilisation des tablespaces InnoDB pour améliorer les temps de récupération sur incident et Utilisation de groupes de paramètres de base de données.

Pour les instances de base de données MySQL qui utilisent la version 5.7 ou ultérieure, vous pouvez dépasser ces limites de création des tables grâce aux progrès faits en termes de récupération d'incident InnoDB. Cependant, nous vous recommandons de faire attention en raison de l'impact potentiel de la création d'un grand nombre de tables sur les performances.

Sur une instance de base de données MySQL, évitez que les tables de votre base de données deviennent trop volumineuses. Bien que la limite du stockage général soit de 64 Tio,les limites de stockage alloué réduisent la taille maximale d'un fichier de table MySQL à 64 To. Partitionnez vos tables volumineuses pour que la taille des fichiers soit inférieure à la limite de 16 To. Cette approche peut également améliorer les performances et le temps de récupération. Pour plus d'informations, consultez Limites de taille des fichiers MySQL.

Les fonctions de restauration à un instant dans le passé et de restauration d'instantané d'Amazon RDS pour MySQL nécessitent un moteur de stockage tolérant aux incidents et sont prises en charge uniquement pour le moteur de stockage InnoDB. Bien que MySQL prenne en charge plusieurs moteurs de stockage avec diverses capacités, toutes ne sont pas optimisées pour la récupération sur incident et la durabilité des données. Par exemple, le moteur de stockage MyISAM ne prend pas en charge une récupération sur incident fiable et peut empêcher la restauration à un instant dans le passé ou la restauration de instantané de fonctionner comme prévu. Cela peut entraîner la perte ou la corruption de données lors du redémarrage de MySQL après un incident.

InnoDB est le moteur de stockage recommandé et pris en charge pour les instances de base de données MySQL sur Amazon RDS. Les instances InnoDB peuvent également être migrées vers Aurora, au contraire des instances MySQL. Toutefois, les performances de MyISAM sont meilleures qu'InnoDB si vous avez besoin de capacités intenses de recherche en texte intégral. Si vous choisissez d'utiliser MyISAM avec Amazon RDS, suivre les étapes décrites dans Sauvegardes automatiques avec moteurs de stockage MySQL non pris en charge peut être utile dans certaines situations pour la fonctionnalité de restauration d'instantané.

Si vous souhaitez convertir les tables MyISAM existantes en tables InnoDB, vous pouvez utiliser le processus décrit dans la documentation MySQL. MyISAM et InnoDB ont des forces et des faiblesses différentes, vous devriez donc commencer par évaluer de façon exhaustive l'impact de ce basculement sur vos applications.

De plus, Federated Storage Engine n'est pour l'instant pas pris en charge par Amazon RDS pour MySQL.

Bonnes pratiques pour utiliser les moteurs de stockage MariaDB

Les fonctions de restauration à un instant dans le passé et de restauration d'instantané d'Amazon RDS pour MariaDB nécessitent un moteur de stockage tolérant aux incidents. Bien que MariaDB prenne en charge plusieurs moteurs de stockage avec diverses capacités, toutes ne sont pas optimisées pour la récupération sur incident et la durabilité des données. Par exemple, bien qu'Aria soit un remplacement sûr en cas d'incident pour MyISAM, il peut empêcher une restauration à un instant dans le passé ou la restauration de snapshot de fonctionner comme prévu. Cela peut entraîner la perte ou la corruption de données lors du redémarrage de MariaDB après un incident. InnoDB (pour la version 10.2 et les versions suivantes) et XtraDB (pour les versions 10.0 et 10.1) sont les moteurs de stockage recommandés et pris en charge pour les instances de base de données MariaDB sur Amazon RDS. Si vous choisissez d'utiliser Aria avec Amazon RDS, suivre les étapes décrites dans Sauvegardes automatiques avec moteurs de stockage MariaDB non pris en charge peut être utile dans certaines situations pour la fonctionnalité de restauration d'instantané.

Bonnes pratiques d'utilisation d'Oracle

Pour obtenir plus d'informations sur les bonnes pratiques d'utilisation de Amazon RDS pour Oracle, consultez Bonnes pratiques pour l'exécution d'une base de données Oracle sur Amazon Web Services et la vidéo Exécution des bases de données Oracle sur Amazon RDS.

Bonnes pratiques pour utiliser les moteurs de stockage PostgreSQL

Les deux principaux domaines dans lesquels vous pouvez améliorer les performances avec PostgreSQL sur Amazon RDS sont lorsque vous chargez des données dans une instance de base de données ou que vous utilisez la fonction autovacuum de PostgreSQL. Les sections suivantes couvrent certaines pratiques que nous recommandons pour ces domaines en particulier.

Chargement des données dans une instance de base de données PostgreSQL

Lors du chargement des données dans une instance de base de données PostgreSQL Amazon RDS, vous devez modifier les paramètres de l'instance et les valeurs du groupe de paramètres de base de données pour permettre l'importation la plus efficace possible des données dans votre instance de base de données.

Modifiez les paramètres de l'instance de base de données comme suit :

  • Désactivez les sauvegardes de l'instance de base de données (affectez la valeur 0 à backup_retention)

  • Désactivez le mode multi-AZ

Modifiez votre groupe de paramètres DB pour inclure les paramètres suivants. Vous devez tester les réglages des paramètres pour déterminer les réglages les plus efficaces pour votre instance de base de données :

  • Augmentez la valeur du paramètre maintenance_work_mem. Pour plus d'informations sur l'utilisation de la ressource PostgreSQL, consultez la documentation sur PostgreSQL.

  • Augmentez la valeur des paramètres checkpoint_segments et checkpoint_timeout pour réduire le nombre d'écritures dans le journal wal.

  • Désactivez le paramètre synchronous_commit (ne désactivez pas FSYNC).

  • Désactivez le paramètre autovacuum de PostgreSQL.

  • Assurez-vous qu'aucune des tables que vous importez n'est pas journalisée. Les données stockées dans les tables non journalisées peuvent être perdues lors d'un basculement. Pour plus d'informations, consultez CREATE TABLE UNLOGGED

Utilisez les commandes pg_dump -Fc (compressé) ou pg_restore -j (parallèle) avec ces paramètres.

Utilisation des paramètres de base de données fsync et full_page_writes

Dans PostgreSQL 9.4.1 sur Amazon RDS, les paramètres de base de données fsync et full_page_writes ne sont pas modifiables. La désactivation des paramètres de base de données fsync et full_page_writes peut entraîner une altération des données, si bien que nous ne les avons activés pour vous. Nous recommandons que les clients utilisant d'autres versions du moteur de base de données PostgreSQL que la version 9.3 ne désactivent pas les paramètres fsync et full_page_writes.

Utilisation de la fonction autovacuum de PostgreSQL

La fonction autovacuum pour les bases de données PostgreSQL est une fonction que nous vous recommandons vivement d'utiliser pour maintenir l'état de votre instance de bases de données PostgreSQL. Autovacuum automatise l'exécution des commandes VACUUM et ANALYZE ; son utilisation est exigée par PostgreSQL, non imposée par Amazon RDS et essentielle pour garantir de bonnes performances. La fonction est activée par défaut pour toutes les nouvelles instances de bases de données PostgreSQL Amazon RDS, et les paramètres de configuration associés sont configurés par défaut de manière appropriée.

Votre administrateur de base de données doit connaître et comprendre cette opération de maintenance. Pour obtenir de la documentation PostgreSQL sur autovacuum, consultez http://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM.

Autovacuum n'est pas une opération « sans utilisation de ressources », mais elle fonctionne en arrière-plan et profite autant que possible aux opérations utilisateur. Lorsqu'elle est activée, la fonction autovacuum vérifie les tables ayant eu un grand nombre de tuples mis à jour ou supprimés. Elle protège également contre la perte de données très anciennes due au renvoi à la ligne de l'ID de transaction.

Autovacuum ne doit pas être considérée comme une opération aux frais généraux élevés qui peut être réduite pour améliorer les performances. Au contraire, les tables qui mettent à jour et suppriment très rapidement se détériorent vite avec le temps si la fonction autovacuum n'est pas exécutée.

Important

La non-exécution de la fonction autovacuum peut entraîner un arrêt obligatoire ultérieur pour effectuer une opération de nettoyage bien plus intrusive. Lorsqu'une instance de base de données PostgreSQL Amazon RDS devient indisponible en raison d'une faible utilisation d'autovacuum, la base de données PostgreSQL se ferme pour se protéger. À ce stade, Amazon RDS doit effectuer un nettoyage complet en mode utilisateur unique directement sur l'instance de base de données, ce qui peut entraîner un arrêt de plusieurs heures. Nous vous recommandons donc vivement de ne pas désactiver la fonction autovacuum, qui est activée par défaut.

Les paramètres d'autovacuum déterminent sa fréquence et son intensité de travail. Les paramètres autovacuum_vacuum_threshold et autovacuum_vacuum_scale_factor déterminent le moment où la fonction autovacuum est exécutée. Les paramètres autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit et autovacuum_cost_delay déterminent l'intensité de travail d'autovacuum. Pour plus d'informations sur la fonction autovacuum, son exécution et les paramètres obligatoires, consultez la documentation sur PostgreSQL.

La requête suivante indique le nombre de tuples « inactifs » dans une table appelée table1 :

PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname =  'table1' order by n_dead_tup desc;

Les résultats de la requête ressembleront à l'exemple ci-dessous :

relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

Bonnes pratiques pour l'utilisation de SQL Server

Les bonnes pratiques pour un déploiement multi-AZ avec une instance de base de données SQL Server sont les suivantes :

  • Utilisez les événements de base de données Amazon RDS pour surveiller les basculements. Par exemple, vous pouvez être notifié par sms ou e-mail en cas de basculement d'une instance de base de données. Pour plus d'informations sur les événements Amazon RDS, consultez Utilisation de la notification d'événement Amazon RDS

  • Si votre application met en cache des valeurs DNS, configurez la durée de vie à moins de 30 secondes. La configuration de la durée de vie est une bonne pratique en tant que tel en cas de basculement, car l'adresse IP peut changer et la valeur mise en cache peut ne plus être en service.

  • Nous vous recommandons de ne pas activer les modes suivants car ils désactivent la journalisation des transactions, qui est obligatoire pour le déploiement multi-AZ :

    • Mode de récupération simple

    • Mode hors ligne

    • Mode lecture seule

  • Testez pour déterminer combien de temps votre instance de base de données met-elle pour basculer. Les délais de basculement peuvent varier en raison du type de base de données, la classe d'instance et le type de stockage utilisé. Vous devez également tester la capacité de votre application à continuer de fonctionner en cas de basculement.

  • Pour raccourcir les délais de basculement, vous devez procéder comme suit :

    • Veillez à avoir suffisamment d'IOPS provisionnées allouées pour votre charge de travail. Des I/O inadaptées peuvent augmenter les délais de basculement. La récupération d'une base de données exige des I/O.

    • Utilisez de plus petites transactions. La récupération de la base de données repose sur les transactions, donc si vous pouvez séparer d'importantes transactions en plusieurs transactions plus petites, vos délais de basculement devraient diminuer.

  • Pensez que lors d'un basculement, les temps de latence sont élevés. Dans le cadre d'un processus de basculement, Amazon RDS réplique automatiquement vos données vers une nouvelle instance de secours. Cette réplication signifie que de nouvelles données sont copiées dans deux instances de base de données différentes, il se peut donc qu'il y ait une certaine latence jusqu'à ce que l'instance de base de données de secours rattrape la nouvelle instance de base de données principale.

  • Déployez vos applications dans toutes les zones de disponibilité. Si une zone de disponibilité tombe en panne, vos applications qui se trouvent dans les autres zones de disponibilité seront toujours disponibles.

Lorsque vous travaillez avec un déploiement multi-AZ de SQL Server, rappelez-vous qu'Amazon RDS crée des réplicas pour toutes les bases de données SQL Server sur votre instance. Si vous ne souhaitez pas que des bases de données spécifiques aient des réplicas secondaires, configurez une instance de base de données séparée qui n'utilise pas de déploiement multi-AZ pour ces bases de données.

Utilisation des groupes de paramètres DB

Nous vous recommandons de tester les modifications apportées aux groupes de paramètres de base de données sur une instance de base de données test avant d'appliquer ces modifications à vos instances de base de données de production. La configuration incorrecte de paramètres de moteur DB dans un groupe de paramètres de base de données peut avoir des effets contraires involontaires, notamment une dégradation de la performance et une instabilité du système. Montrez-vous toujours prudent lorsque vous modifiez des paramètres de moteur DB et sauvegardez votre instance de base de données avant de modifier un groupe de paramètres de base de données.

Pour plus d'informations sur la sauvegarde de votre instance de base de données, consultez Sauvegarde et restauration des instances de base de données Amazon RDS.

Vidéo de présentation des bonnes pratiques pour Amazon RDS

La conférence du 2016 AWS Summit qui s'est tenue à Chicago incluait une présentation des meilleures pratiques pour créer et configurer une instance de base de données sécurisée et hautement disponible à l'aide de Amazon RDS. Une vidéo de la présentation est disponible ici: