Bonnes pratiques pour Amazon RDS

Découvrez les meilleures pratiques pour travailler avec AmazonRDS. Nous mettrons à jour cette section à mesure que de nouvelles bonnes pratiques seront identifiées.

Note

Pour des recommandations courantes pour AmazonRDS, consultezRecommandations d'Amazon RDS.

Directives opérationnelles RDS de base d'Amazon

Vous trouverez ci-dessous des directives opérationnelles de base que tout le monde doit suivre lorsqu'il travaille avec AmazonRDS. Notez que l'accord de niveau RDS de service Amazon exige que vous suiviez les directives suivantes :

• Utilisez des métriques pour surveiller votre mémoireCPU, le délai de réplication et l'utilisation du stockage. Vous pouvez configurer Amazon CloudWatch pour qu'il vous avertisse lorsque les habitudes d'utilisation changent ou lorsque votre déploiement approche des limites de capacité. Cela vous permet de 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 la fenêtre de sauvegarde de manière à ce qu'elle se produise pendant le creux quotidien en écritureIOPS. C'est à ce moment qu'une sauvegarde perturbe le moins l'utilisation de votre base de données.

• 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 différente avec une forte capacité d'E/S.

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

    Si vous passez au IOPS stockage provisionné, assurez-vous d'utiliser également une classe d'instance de base de données optimisée pour le stockage IOPS provisionné. Pour plus d'informations sur ProvisionedIOPS, consultezStockage provisionné IOPS SSD.

  • Si vous utilisez déjà le IOPS stockage provisionné, allouez une capacité de débit supplémentaire.

• Si votre application cliente met en cache les données du service de noms de domaine (DNS) de vos instances de base de données, définissez une valeur time-to-live (TTL) inférieure à 30 secondes. L'adresse IP sous-jacente d'une instance de base de données peut changer après un basculement. La mise en cache prolongée DNS des données peut donc entraîner des échecs de connexion. Il se peut que votre application essaie 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 particulier. Le basculement permet également de 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.

RAMRecommandations relatives aux instances de base de

L'une RDS des meilleures pratiques d'Amazon en matière de performances consiste à en allouer suffisamment pour RAM que votre poste de travail réside presque entièrement en mémoire. L'ensemble de travail est les données et les index fréquemment utilisés sur votre instance. Plus vous utilisez l'instance de base de données, plus l'ensemble de travail se développera.

Pour savoir si votre ensemble de travail est presque entièrement en mémoire, vérifiez la IOPS métrique Read (à l'aide d'Amazon CloudWatch) lorsque l'instance de base de données est en charge. La valeur de Read IOPS doit être faible et stable. Dans certains cas, le fait de transformer la classe d'instance de base de données en une classe contenant plus de classes RAM entraîne une baisse spectaculaire du nombre de lecturesIOPS. Dans ces cas, votre ensemble de travail n'était pas presque entièrement en mémoire. Continuez à augmenter l'échelle jusqu'à ce que Read IOPS ne baisse plus de façon spectaculaire après une opération de redimensionnement, ou jusqu'à IOPS ce que Read soit réduit à une très petite quantité. Pour plus d'informations sur la supervision des métriques d'une instance de base de données, consultez Afficher les métriques dans la RDS console Amazon.

AWS pilotes de base de données

Nous vous recommandons le AWS suite de pilotes pour la connectivité des applications. Les pilotes ont été conçus pour accélérer les temps de basculement et de basculement, ainsi que pour permettre l'authentification avec AWS Secrets Manager, AWS Identity and Access Management (IAM), et Federated Identity. Le AWS les pilotes s'appuient sur la surveillance de l'état de l'instance de base de données et sur la connaissance de la topologie de l'instance pour déterminer le nouveau rédacteur. Cette approche réduit les temps de basculement et de basculement à un chiffre, contre des dizaines de secondes pour les pilotes open source.

À mesure que de nouvelles fonctionnalités de service sont introduites, l'objectif du AWS La suite de pilotes doit avoir un support intégré pour ces fonctionnalités de service.

Pour de plus amples informations, veuillez consulter Connexion aux instances de base de données avec les AWS pilotes.

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

Lorsque la surveillance améliorée est activée, Amazon RDS fournit des métriques en temps réel pour le système d'exploitation (OS) sur lequel votre instance de base de données s'exécute. Vous pouvez afficher les métriques de votre instance de base de données à l'aide de la console. Vous pouvez également utiliser les JSON résultats 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 la section Surveillance des métriques du système d'exploitation à l'aide de la Surveillance améliorée.

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

Pour identifier les problèmes de performances dus à des ressources insuffisantes et à d'autres blocages courants, vous pouvez surveiller les métriques disponibles pour votre instance de base de données AmazonRDS.

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 définir des CloudWatch alarmes Amazon pour des seuils métriques spécifiques afin d'être alerté s'ils sont atteints.

Pour résoudre les problèmes de performances, il est important de comprendre les performances de base du système. Lorsque vous configurez une instance de base de données et que vous l'exécutez avec une charge de travail classique, capturez les valeurs moyenne, maximale et minimale de toutes les mesures de performance. Faites-le à différents intervalles (par exemple, une heure, 24 heures, une semaine, deux semaines). Cela vous permet de vous faire une idée de ce qui est normal. 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 les clusters de bases de données multi-AZ, surveillez la différence de temps entre la dernière transaction sur l'instance de base de données de rédacteur et la dernière transaction appliquée sur une instance de base de données de lecteur. Cette différence s'appelle décalage (retard) de réplica. Pour de plus amples informations, veuillez consulter Retard de réplica et clusters de base de données multi-AZ.

Vous pouvez consulter les CloudWatch statistiques et les statistiques combinées dans le tableau de bord Performance Insights et surveiller votre instance de base de données. Si vous souhaitez utiliser cette vue de surveillance, Performance Insights doit être activé pour votre instance de base de données. Pour obtenir des informations sur cette vue de surveillance, consultez Afficher les indicateurs combinés avec le tableau de bord Performance Insights.

Vous pouvez créer un rapport d'analyse des performances pour une période spécifique et consulter les informations identifiées et les recommandations pour résoudre les problèmes. Pour de plus amples informations, veuillez consulter Création d'un rapport d'analyse des performances dans Performance Insights.

Pour consulter les métriques de performances

1. Connectez-vous au AWS Management Console et ouvrez la RDS console Amazon à 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.

   Le tableau de bord fournit les métriques de performances. Les métriques affichent par défaut les informations des trois dernières heures.

4. Utilisez les boutons numérotés dans l'angle supérieur droit de la page pour parcourir les autres métriques ou ajustez 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, vous pouvez consulter les valeurs maximales d'une métrique pour chaque jour des deux dernières semaines. Si tel est le cas, définissez Statistic (Statistiques) sur Maximum, Time Range (Plage de temps) sur Last 2 Weeks (Deux dernières semaines) et Period (Période) sur Day (Jour).

Vous pouvez également consulter les indicateurs de performance à l'aide du CLI ouAPI. Pour de plus amples informations, veuillez consulter Afficher les métriques dans la RDS console Amazon.

Pour régler une CloudWatch alarme

1. Connectez-vous au AWS Management Console et ouvrez la RDS console Amazon à 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 CloudWatch des alarmes, choisissez Créer une alarme.

   

5. Pour Envoyer des notifications, choisissez Oui, et pour Envoyer des notifications à, choisissez Nouvel e-mail ou nouveau SMS sujet.

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. Sous Evaluation period (Période d'évaluation), choisissez la période d'évaluation de l'alarme. Pour consecutive period(s) of (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 des CloudWatch alarmes.

Évaluation 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.

CPU

• CPUUtilisation — Pourcentage de la capacité de traitement informatique utilisée.

Mémoire

• Mémoire disponible : quantité RAM disponible sur l'instance de base de données, en octets. La ligne rouge dans les métriques de l'onglet Surveillance est marquée à 75 % pour CPU les métriques 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.

• Utilisation du swap : quantité d'espace de swap utilisée 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

• LectureIOPS, écriture IOPS : nombre moyen d'opérations de lecture ou d'écriture sur le 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'E/S 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 métriques de performances disponibles, veuillez consulter Surveillance des métriques RDS avec Amazon CloudWatch.

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 :

• Haute CPU RAM consommation — Des valeurs élevées pour CPU ou pour RAM la consommation peuvent être appropriées. Par exemple, elles peuvent être élevées si elles sont conformes aux objectifs pour votre application (comme le débit ou la simultanéité) et sont attendues.

• 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. Pour déterminer le nombre de connexions de la base de données, associez votre instance de base de données à un groupe de paramètres. Dans ce groupe, définissez le paramètre User Connections (Connexions utilisateurs) sur une valeur autre que 0 (illimitée). Vous pouvez utiliser un groupe de paramètres existant ou en créer un nouveau. Pour de plus amples informations, veuillez consulter Groupes de paramètres pour Amazon RDS.

• IOPSmétriques — Les valeurs attendues pour les IOPS métriques dépendent des spécifications du disque et de la configuration du serveur. Utilisez donc votre référence pour savoir ce qui est typique. Enquêtez si les valeurs sont constamment différentes de vos données de référence. Pour des IOPS performances optimales, assurez-vous que votre ensemble de travail habituel tient bien en mémoire afin de minimiser les opérations de lecture et d'écriture.

Pour les problèmes liés aux indicateurs de performance, la première étape pour améliorer les performances consiste à ajuster les requêtes les plus utilisées et les plus coûteuses. Ajustez-les pour voir si cela réduit la pression sur les ressources du système. Pour de plus amples informations, veuillez consulter Réglage des requêtes.

Si vos requêtes sont réglées et que le problème persiste, envisagez de mettre à niveau votre Amazon RDSClasses d'instances de base de données . Vous pouvez le mettre à niveau vers un autre avec une plus grande partie des ressources (CPURAM,, espace disque, bande passante réseau, capacité d'E/S) associées au problème.

Réglage des requêtes

L'un des meilleurs moyens d'améliorer les performances d'une instance de base de données est d'ajuster les requêtes les plus communément utilisées et exigeantes en ressources. Ici, vous les ajustez pour les rendre moins onéreuses à utiliser. Pour plus d'informations sur l'amélioration des requêtes, utilisez les ressources suivantes :

• Mon SQL — Voir Optimisation SELECT des instructions dans la SQL documentation Mon. Pour des ressources supplémentaires de réglage des requêtes, voir Mes ressources de réglage et d'optimisation des SQL performances.

• Oracle — Voir le guide de SQL réglage des bases de données dans la documentation de la base de données Oracle.

• SQLServeur : voir Analyse d'une requête dans la documentation Microsoft. Vous pouvez également utiliser les vues de gestion des données relatives à l'exécution, à l'index et aux E/S (DMVs) décrites dans les vues de gestion dynamique du système de la documentation Microsoft pour résoudre les problèmes liés aux requêtes SQL du serveur.

  Un aspect courant du réglage de requête est la création d'index efficaces. Pour des améliorations potentielles de l'index de votre instance de base de données, consultez Assistant Paramétrage du moteur de base de données dans la documentation Microsoft. Pour plus d'informations sur l'utilisation de Tuning Advisor on RDS for SQL Server, consultezAnalyse de la charge de travail d'une base de données sur une instance de base de données Amazon RDS for SQL Server avec l'Assistant Paramétrage du moteur de base de données.

• Postgre SQL — Voir Utilisation EXPLAIN dans la SQL documentation de Postgre pour savoir comment analyser un plan de requêtes. Vous pouvez utiliser ces informations pour modifier une requête ou des tables sous-jacentes afin d'améliorer les performances des requêtes.

  Pour plus d'informations sur la manière de spécifier des jointures dans votre requête afin d'optimiser les performances, consultez la section Contrôle du planificateur à l'aide de JOIN clauses explicites.

• MariaDB – Consultez Optimisations de requête dans la documentation MariaDB.

Bonnes pratiques pour travailler avec My SQL

La taille des tables et le nombre de tables dans une base de SQL données Ma base de données peuvent affecter les performances.

Taille des tables

Généralement, les contraintes du système d'exploitation relatives à la taille des fichiers déterminent la taille de table maximale effective pour Mes SQL bases de données. Ainsi, les limites ne sont généralement pas déterminées par les SQL contraintes internes de My.

Sur une instance My SQL DB, évitez que les tables de votre base de données ne deviennent trop volumineuses. Bien que la limite de stockage générale soit de 64 TiB, les limites de stockage provisionnées limitent la taille maximale d'un fichier My SQL table à 16 TiB. 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 de plus amples informations, veuillez consulter Mes limites de taille de SQL fichier sur Amazon RDS.

Les tables très volumineuses (d'une taille supérieure à 100 Go) peuvent avoir une incidence négative sur les performances de lecture et d'écriture (y compris DML les instructions, en particulier DDL les instructions). Les index sur de grandes tables peuvent améliorer de manière significative les performances des sélections, mais ils peuvent également dégrader les performances des DML relevés. DDLles instructions, telles queALTER TABLE, peuvent être considérablement plus lentes pour les grandes tables, car ces opérations peuvent dans certains cas reconstruire complètement une table. Ces DDL instructions peuvent verrouiller les tables pendant la durée de l'opération.

La quantité de mémoire requise par My SQL pour les lectures et les écritures dépend des tables impliquées dans les opérations. Il est recommandé d'en avoir au moins suffisamment RAM pour contenir les index des tables activement utilisées. Pour rechercher les dix tables et index les plus volumineux d'une base de données, utilisez la requête suivante :

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Nombre de tables

Votre système de fichiers sous-jacent peut imposer des limites en termes de nombre de fichiers représentant les tables. Cependant, My SQL n'impose aucune limite quant au nombre de tables. Malgré cela, le nombre total de tables dans le moteur de stockage My SQL InnoDB peut contribuer à la dégradation des performances, quelle que soit la taille de ces tables. Pour limiter l'impact sur le système d'exploitation, vous pouvez répartir les tables entre plusieurs bases de données dans la même instance My SQL DB. Cela limitera éventuellement le nombre de fichiers contenus dans un répertoire mais ne résoudra pas le problème global.

Lorsque les performances se dégradent en raison d'un grand nombre de tables (plus de 10 000), cela est dû au fait que je SQL travaille avec des fichiers de stockage, notamment en les ouvrant et en les fermant. Pour résoudre ce problème, vous pouvez augmenter la taille des paramètres table_open_cache et table_definition_cache. Cependant, l'augmentation des valeurs de ces paramètres peut augmenter de manière significative la quantité de mémoire que My SQL utilise, voire utiliser toute la mémoire disponible. Pour plus d'informations, consultez la section Comment mon SQL ordinateur ouvre et ferme des tables dans la SQL documentation Ma documentation.

En outre, un trop grand nombre de tables peut affecter de manière significative le temps de SQL démarrage de My Startup. Un arrêt et un redémarrage complets ainsi qu'une reprise après incident peuvent être affectés, en particulier dans les versions antérieures à My SQL 8.0.

Nous recommandons de maintenir le nombre total de tables en dessous de 10 000 dans toutes les bases de données d'une instance de base de données. Pour un cas d'utilisation impliquant un grand nombre de tables dans une SQL base de données My, voir One Million Tables in My SQL 8.0.

Moteur de stockage

Les fonctionnalités de point-in-time restauration et de restauration de snapshots d'Amazon RDS for My SQL nécessitent un moteur de stockage récupérable en cas de panne. Ces fonctions sont uniquement prises en charge pour le moteur de stockage InnoDB. Bien que My SQL prenne en charge plusieurs moteurs de stockage dotés de fonctionnalités différentes, ils ne sont pas tous optimisés pour la reprise après incident et la durabilité des données. Par exemple, le moteur My ISAM Storage ne prend pas en charge une restauration fiable en cas de panne et peut empêcher une point-in-time restauration ou une restauration instantanée de fonctionner comme prévu. Cela peut entraîner la perte ou la corruption de données lorsque My SQL est redémarré après un crash.

InnoDB est le moteur de stockage recommandé et pris en charge pour les instances My SQL DB sur Amazon. RDS Les instances InnoDB peuvent également être migrées vers Aurora, tandis que Mes ISAM instances ne peuvent pas être migrées. Cependant, My est plus ISAM performant qu'InnoDB si vous avez besoin d'une capacité de recherche intense en texte intégral. Si vous choisissez toujours d'utiliser My ISAM with AmazonRDS, il Sauvegardes automatisées avec des moteurs My SQL Storage non pris en charge peut être utile de suivre les étapes décrites dans certains scénarios pour la fonctionnalité de restauration des instantanés.

Si vous souhaitez convertir des ISAM tables My existantes en tables InnoDB, vous pouvez utiliser le processus décrit dans la section Conversion de tables de My vers ISAM InnoDB dans la documentation My. SQL InnoDB ISAM et moi-même avons des forces et des faiblesses différentes. Vous devez donc évaluer pleinement l'impact de cette transition sur vos applications avant de le faire.

En outre, le moteur de stockage fédéré n'est actuellement pas pris en charge par Amazon RDS for MySQL.

Bonnes pratiques d'utilisation de MariaDB

La taille et le nombre des tables contenues dans une base de données MariaDB peuvent tous deux nuire aux performances.

Taille des tables

En règle générale, les contraintes imposées par le système d'exploitation sur la taille des fichiers déterminent la taille maximale effective des tables des bases de données MariaDB. Par conséquent, les limites ne dépendent généralement pas de contraintes internes de MariaDB.

Sur une instance de base de données MariaDB, veillez à ce que les tables de votre base de données ne deviennent pas 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 MariaDB à 16 Tio. 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.

Les tables très volumineuses (d'une taille supérieure à 100 Go) peuvent avoir une incidence négative sur les performances de lecture et d'écriture (y compris DML les instructions, en particulier DDL les instructions). Les index sur de grandes tables peuvent améliorer de manière significative les performances des sélections, mais ils peuvent également dégrader les performances des DML relevés. DDLles instructions, telles queALTER TABLE, peuvent être considérablement plus lentes pour les grandes tables, car ces opérations peuvent dans certains cas reconstruire complètement une table. Ces DDL instructions peuvent verrouiller les tables pendant la durée de l'opération.

La quantité de mémoire requise par MariaDB pour les lectures et les écritures dépend des tables impliquées dans les opérations. Il est recommandé d'en avoir au moins suffisamment RAM pour contenir les index des tables activement utilisées. Pour rechercher les dix tables et index les plus volumineux d'une base de données, utilisez la requête suivante :

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Nombre de tables

Votre système de fichiers sous-jacent peut imposer des limites en termes de nombre de fichiers représentant les tables. Cependant, MariaDB n'a aucune limite quant au nombre de tables. Cela dit, le nombre total de tables contenues dans le moteur de stockage MariaDB InnoDB peut contribuer à la dégradation des performances, quelle que soit la taille de ces tables. Pour limiter l'impact sur le système d'exploitation, vous pouvez répartir les tables entre plusieurs bases de données de la même instance de base de données MariaDB. Cela limitera éventuellement le nombre de fichiers contenus dans un répertoire mais ne résoudra pas le problème global.

Toute dégradation des performances liée à la présence d'un grand nombre de tables (plus de 10 000) est due au fait que MariaDB intervient sur les fichiers de stockage. Ce travail inclut l'ouverture et la fermeture de fichiers de stockage par MariaDB. Pour résoudre ce problème, vous pouvez augmenter la taille des paramètres table_open_cache et table_definition_cache. L'augmentation des valeurs de ces paramètres peut toutefois augmenter la quantité de mémoire utilisée par MariaDB. Elle peut même utiliser toute la mémoire disponible. Pour plus d'informations, consultez Optimisation de table_open_cache dans la documentation MariaDB.

En outre, la présence d'un trop grand nombre de tables peut avoir un impact significatif sur le temps de démarrage de MariaDB. L'arrêt et le redémarrage propres ainsi que la reprise sur incident peuvent être affectés. Nous recommandons de maintenir le nombre total de tables en dessous de dix mille dans toutes les bases de données d'une instance de base de données.

Moteur de stockage

Les fonctionnalités de point-in-time restauration et de restauration de snapshots d'Amazon RDS pour MariaDB nécessitent un moteur de stockage récupérable en cas de panne. 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, même si Aria remplace My en toute sécuritéISAM, il peut empêcher une point-in-time restauration ou une restauration instantanée 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 est le moteur de stockage recommandé et pris en charge pour les instances de base de données MariaDB sur Amazon. RDS Si vous choisissez toujours d'utiliser Aria avec AmazonRDS, il Sauvegardes automatiques avec moteurs de stockage MariaDB non pris en charge peut être utile de suivre les étapes décrites dans certains scénarios pour la fonctionnalité de restauration des instantanés.

Si vous souhaitez convertir des ISAM tables My existantes en tables InnoDB, vous pouvez utiliser le processus décrit dans la section Conversion de tables de My en ISAM InnoDB dans la documentation de MariaDB. InnoDB ISAM et moi-même avons des forces et des faiblesses différentes. Vous devez donc évaluer pleinement l'impact de cette transition sur vos applications avant de le faire.

Bonnes pratiques d'utilisation d'Oracle

Pour plus d'informations sur les meilleures pratiques relatives à l'utilisation d'Amazon RDS pour Oracle, consultez la section Meilleures pratiques pour exécuter la base de données Oracle sur Amazon Web Services.

EN 2020 AWS l'atelier virtuel comprenait une présentation sur l'exécution de bases de données Oracle de production sur AmazonRDS. Une vidéo de la présentation est disponible ici:

Bonnes pratiques pour travailler avec Postgre SQL

Parmi les deux domaines importants dans lesquels vous pouvez améliorer les performances RDS de PostgreSQL, l'un est le chargement de données dans une instance de base de données. Une autre solution est l'utilisation de la fonction d'SQLaspiration automatique Postgre. Les sections suivantes couvrent certaines pratiques que nous recommandons pour ces domaines en particulier.

Pour plus d'informations sur la manière dont Amazon RDS implémente d'autres SQL DBA tâches Postgre courantes, consultezTâches courantes d'administration de bases de données pour Amazon RDS for PostgreSQL.

Chargement de données dans une instance de SQL base de données Postgre

Lorsque vous chargez des données dans une instance de base de données Amazon RDS pour Postgre, modifiez les paramètres de votre SQL instance de base de données et les valeurs de vos groupes de paramètres de base de données. Définissez-les pour permettre l'importation de données la plus efficace possible 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. Testez également 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 les paramètres de consommation SQL des ressources Postgre, consultez la documentation Postgre SQL.

• Augmentez la valeur des checkpoint_timeout paramètres max_wal_size et pour réduire le nombre d'écritures dans le journal write-ahead log (WAL).

• Désactivez le paramètre synchronous_commit.

• Désactivez le paramètre Postgre SQL Autovacuum.

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

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

Une fois l'opération de chargement terminée, réinitialisez votre instance de base de données et les paramètres de base de données à leurs paramètres normaux.

Utilisation de la fonction SQL Autovacuum de Postgre

La fonction autovacuum pour les SQL bases de données Postgre est une fonctionnalité que nous vous recommandons vivement d'utiliser pour maintenir l'intégrité de votre instance de base de données PostgreSQL. Autovacuum automatise l'exécution de la ANALYZE commande VACUUM and. L'utilisation d'autovacuum est requise par PostgreSQL, et non imposée par AmazonRDS, et son utilisation est essentielle à de bonnes performances. La fonctionnalité est activée par défaut pour toutes les nouvelles SQL instances de base de données Amazon RDS pour Postgre, et les paramètres de configuration associés sont correctement définis par défaut.

Votre administrateur de base de données doit connaître et comprendre cette opération de maintenance. Pour la SQL documentation Postgre sur Autovacuum, consultez The Autovacuum Daemon.

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. Pour de plus amples informations, veuillez consulter Preventing Transaction ID Wraparound Failures.

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. Dans certains cas, une SQL instance de base RDS de données Postgre peut devenir indisponible en raison d'une utilisation trop prudente de l'autovacuum. Dans ces cas, la base de SQL données Postgre s'arrête pour se protéger. À ce stade, Amazon RDS doit effectuer un nettoyage single-user-mode complet directement sur l'instance de base de données. Ce vacuum complet peut entraîner une panne 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ètresautovacuum_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 l'autovacuum, son mode d'exécution et les paramètres requis, consultez la section Routine Vacuuming dans la documentation Postgre. SQL

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

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

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

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

Vidéo sur RDS les SQL meilleures pratiques d'Amazon pour Postgre

Le 2020 AWS La conférence re:Invent comprenait une présentation sur les nouvelles fonctionnalités et les meilleures pratiques pour travailler avec Postgre sur AmazonSQL. RDS Une vidéo de la présentation est disponible ici:

Bonnes pratiques d'utilisation du SQL serveur

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

• Utilisez les événements Amazon RDS DB 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 RDS événements Amazon, consultezUtilisation des notifications d'RDSévénements Amazon.

• Si votre application met des DNS valeurs en cache, réglez la durée de vie (TTL) à moins de 30 secondes. Un TTL tel réglage est une bonne pratique en cas de basculement. Lors d'un basculement, 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, procédez comme suit :

  • Assurez-vous que le provisionnement IOPS alloué est suffisant 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 du processus de basculement, Amazon réplique RDS automatiquement vos données sur une nouvelle instance de secours. Cette réplication signifie que de nouvelles données sont transférées vers deux instances de base de données différentes. Il peut donc y avoir 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 sur un déploiement multi-AZ de SQL Server, n'oubliez pas qu'Amazon RDS crée des répliques pour toutes les bases de données SQL Server de 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.

Vidéo sur RDS les meilleures pratiques d'Amazon for SQL Server

Le 2019 AWS La conférence re:Invent comprenait une présentation sur les nouvelles fonctionnalités et les meilleures pratiques relatives à l'utilisation de SQL Server sur Amazon. RDS Une vidéo de la présentation est disponible ici:

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, restauration et exportation de données.

Bonnes pratiques pour automatiser la création d'instances de base de données

Amazon recommande de créer RDS une instance de base de données avec la version mineure préférée du moteur de base de données. Vous pouvez utiliser le plugin AWS CLI RDSAPI, Amazon ou AWS CloudFormation pour automatiser la création d'instances de base de données. Lorsque vous utilisez ces méthodes, vous ne pouvez spécifier que la version principale et Amazon crée RDS automatiquement l'instance avec la version secondaire préférée. Par exemple, si Postgre SQL 12.5 est la version mineure préférée, et si vous spécifiez la version 12 aveccreate-db-instance, l'instance de base de données sera la version 12.5.

Pour déterminer la version mineure préférée, vous pouvez exécuter la commande describe-db-engine-versions avec l'option --default-only, comme illustré dans l'exemple suivant.

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

Pour plus d'informations sur la création d'instances de base de données par programmation, consultez les ressources suivantes :

• Utilisation de AWS CLI – create-db-instance

• Utilisation de l'Amazon RDS API — C reateDBInstance

• Utilisation AWS CloudFormation – AWS::RDS::DBInstance

Vidéo sur les RDS nouvelles fonctionnalités d'Amazon

Le 2023 AWS La conférence re:Invent comprenait une présentation sur les nouvelles fonctionnalités d'AmazonRDS. Une vidéo de la présentation est disponible ici: