Stockage et fiabilité d'Amazon Aurora

Vous pouvez découvrir ci-après le sous-système de stockage Aurora. Aurora utilise une architecture de stockage distribuée et partagée qui est un facteur important en matière de performances, d'évolutivité et de fiabilité pour les clusters Aurora.

Présentation du stockage Amazon Aurora

Les données Aurora sont stockées dans le volume de cluster, qui est un seul volume virtuel et utilise des disques SSD. Un volume de cluster se compose de copies des données couvrant trois zones de disponibilité d'une même région AWS. Comme les données sont automatiquement répliquées à travers les zones de disponibilité, vos données sont hautement durables, avec une possibilité moindre de perte des données. Cette réplication garantit aussi que votre base de données est plus disponible pendant un basculement. En effet, les copies de données existent déjà dans les autres zones de disponibilité et continuent de traiter les demandes de données adressées aux instances de base de données de votre cluster de base de données. Le volume de la réplication est indépendant du nombre d'instances DB de votre cluster.

Aurora utilise un stockage local séparé pour les fichiers temporaires non persistants. Il s'agit notamment des fichiers qui sont utilisés à des fins telles que le tri de grands jeux de données pendant le traitement des requêtes et la génération d'index. Pour plus d’informations, consultez Limites de stockage temporaires pour Aurora MySQL et Limites de stockage temporaires pour Aurora PostgreSQL.

Contenu du volume de cluster

Le volume de cluster Aurora contient toutes les données utilisateur, les objets de schéma et les métadonnées internes, telles que les tables système et le journal binaire. Par exemple, Aurora stocke, entre autres, les tables, les index, les objets BLOB et les procédures stockées d'un cluster Aurora dans un volume de cluster.

L'architecture de stockage partagée d'Aurora sépare vos données des instances de base de données du cluster. Par exemple, vous pouvez ajouter rapidement une instance de base de données, car Aurora n'effectue pas de nouvelle copie des données de la table. Au lieu de cela, l'instance de base de données se connecte au volume partagé qui contient déjà toutes les données. Vous pouvez supprimer une instance de base de données d'un cluster sans avoir à supprimer les données sous-jacentes du cluster. Aurora ne supprime les données que lorsque vous supprimez le cluster entier.

Configurations de stockage pour les clusters de bases de données Amazon Aurora

Amazon Aurora dispose de deux configurations de stockage pour les clusters de bases de données :

• Aurora I/O-Optimized : amélioration du rapport prix/performances et de la prévisibilité pour les applications gourmandes en E/S. Vous ne payez que pour l'utilisation et le stockage de vos clusters de bases de données, sans frais supplémentaires pour les opérations d'E/S en lecture et en écriture.

  Aurora I/O-Optimized est le meilleur choix lorsque vos dépenses d'E/S représentent 25 % ou plus de vos dépenses totales pour la base de données Aurora.

  Vous pouvez choisir Aurora I/O-Optimized lorsque vous créez ou modifiez un cluster de base de données avec une version du moteur de base de données qui prend en charge la configuration du cluster Aurora I/O-Optimized. Vous pouvez passer du type Aurora I/O-Optimized au type Aurora Standard à tout moment.

• Aurora Standard : tarification rentable pour de nombreuses applications avec une utilisation modérée des E/S. Outre l'utilisation et le stockage de vos clusters de bases de données, vous payez également un tarif standard pour 1 million de demandes d'opérations d'E/S.

  Aurora Standard est le meilleur choix lorsque vos dépenses d'E/S représentent moins de 25 % de vos dépenses totales pour la base de données Aurora.

  Vous pouvez passer d'Aurora Standard à Aurora I/O-Optimized une fois tous les 30 jours. Il n'y a aucun temps d'arrêt lorsque vous passez de Aurora Standard Aurora I/O-Optimized à Aurora I/O-Optimized ou deAurora Standard.

Pour obtenir des informations sur la prise en charge de la versions et de la Région AWS, consultez Régions et moteurs de base de données Aurora pris en charge pour les configurations de stockage en cluster.

Pour plus d'informations sur la tarification des configurations de stockage Amazon Aurora, consultez Tarification d'Amazon Aurora.

Pour obtenir des informations sur le choix de la configuration de stockage lors de la création d'un cluster de base de données, consultez Création d'un cluster de base de données. Pour obtenir des informations sur la modification de la configuration de stockage pour un cluster de base de données, consultez Paramètres pour Amazon Aurora.

Redimensionnement automatique du stockage Aurora

Les volumes de cluster Aurora croissent automatiquement au fur et à mesure que la quantité de données de votre base de données augmente. La taille maximale d'un volume de cluster Aurora est de 128 téraoctets (Tio) ou 64 Tio, selon la version du moteur de base de données. Pour plus d'informations sur la taille maximale d'une version spécifique, veuillez consulter Limites de taille Amazon Aurora. Cette mise à l'échelle automatique du stockage est associée à un sous-système de stockage hautement distribué et à hautes performances. Ceci fait d'Aurora un bon choix pour vos données importantes d'entreprise lorsque vos objectifs principaux sont la fiabilité et la haute disponibilité.

Pour afficher le statut du volume, reportez-vous à la section Affichage du statut du volume pour un cluster de base de données Aurora MySQL ou Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL. Pour savoir comment équilibrer les coûts de stockage par rapport aux autres priorités, Dimensionnement du stockage explique comment surveiller les métriques AuroraVolumeBytesLeftTotal et VolumeBytesUsed les entrées d'Amazon Aurora CloudWatch.

Lorsque des données Aurora sont supprimées, l'espace alloué à ces données est libéré. Parmi les exemples de suppression de données, on peut citer la suppression ou la troncation d'une table. Cette réduction automatique de l'utilisation du stockage vous aide à minimiser les frais de stockage.

Note

Les limites de stockage et le comportement de redimensionnement dynamique présentés ici s'appliquent aux tables persistantes et aux autres données stockées dans le volume de cluster.

Pour Aurora PostgreSQL, les données de table temporaires sont stockées dans l'instance de base de données locale.

Pour Aurora MySQL version 2, les données de tables temporaires sont stockées par défaut dans le volume du cluster pour les instances d'écriture et dans le stockage local pour les instances de lecture. Pour plus d'informations, consultez Moteur de stockage pour des tables temporaires sur disque.

Pour Aurora MySQL version 3, les données de tables temporaires sont stockées dans l'instance de base de données locale ou dans le volume du cluster. Pour plus d'informations, consultez Nouveau comportement de table temporaire dans Aurora MySQL version 3.

La taille maximale des tables temporaires résidant dans le stockage local est limitée par la taille de stockage local maximale de l'instance de base de données. La taille de stockage local dépend de la classe d'instance que vous utilisez. Pour plus d’informations, consultez Limites de stockage temporaires pour Aurora MySQL et Limites de stockage temporaires pour Aurora PostgreSQL.

Certaines fonctions de stockage, telles que la taille maximale d'un volume de cluster et le redimensionnement automatique lorsque des données sont supprimées, dépendent de la version Aurora de votre cluster. Pour plus d'informations, consultez Dimensionnement du stockage. Vous pouvez également apprendre à éviter les problèmes de stockage et à surveiller le stockage alloué et l'espace libre dans votre cluster.

Facturation du stockage des données Aurora

Même si un volume de cluster Aurora peut atteindre 128 téraoctets (Tio), vous n'êtes facturé que pour l'espace que vous utilisez dans un volume de cluster Aurora. Dans les versions antérieures d'Aurora, le volume de cluster pouvait réutiliser l'espace libéré lorsque vous supprimiez des données, mais l'espace de stockage alloué ne diminuait jamais. Désormais, lorsque des données Aurora sont supprimées (par exemple, en supprimant une table ou une base de données), l'espace alloué global diminue d'un montant comparable. Ainsi, vous pouvez réduire les frais de stockage en supprimant des tables, des index, des bases de données, etc. dont vous n'avez plus besoin.

Astuce

Pour les versions antérieures sans fonction de redimensionnement dynamique, la réinitialisation de l'utilisation du stockage pour un cluster impliquait la réalisation d'un vidage logique et la restauration vers un nouveau cluster. Cette opération peut prendre beaucoup de temps pour un volume important de données. Le cas échéant, envisagez de mettre à niveau votre cluster vers une version qui prend en charge le redimensionnement du volume dynamique.

Pour plus d'informations sur les versions d'Aurora qui prennent en charge le redimensionnement dynamique et sur la façon de réduire les frais de stockage en surveillant l'utilisation du stockage pour votre cluster, consultez Dimensionnement du stockage. Pour plus d'informations sur la facturation du stockage de sauvegarde Aurora, consultez Comprendre l'utilisation du stockage de sauvegarde Amazon Aurora. Pour obtenir des informations sur la tarification du stockage de données Aurora, consultez la section Tarification de Amazon RDS for Aurora.

Fiabilité Amazon Aurora

Aurora est conçu pour être fiable, durable et tolérant aux pannes. Vous pouvez définir l'architecture de votre cluster de base de données Aurora afin d'améliorer la disponibilité en permettant des actions telles que l'ajout de réplicas Aurora et leur placement dans différentes zones de disponibilité. En outre, Aurora inclut plusieurs fonctions automatiques qui garantissent sa fiabilité en tant que solution de base de données.

Rubriques

• Réparation automatique du stockage
• Cache de page durable
• Reprise après un redémarrage imprévu

Réparation automatique du stockage

Comme Aurora gère plusieurs copies de vos données dans trois zones de disponibilité, le risque de perdre des données suite à une défaillance de disque est considérablement limité. Aurora détecte automatiquement les défaillances au niveau des volumes de disque qui composent le volume de cluster. En cas de défaillance d'un segment d'un volume disque, Aurora répare immédiatement le segment. Quand Aurora répare le segment disque, il utilise les données des autres volumes qui composent le volume de cluster pour garantir que les données du segment réparé sont actives. Aurora évite ainsi les pertes de données et réduit le besoin d'effectuer une point-in-time restauration pour récupérer après une panne de disque.

Cache de page durable

Dans Aurora, le cache de page de chaque instance de base de données est géré dans un processus distinct de la base de données, qui lui permet de « survivre » indépendamment de la base de données. (Le cache de page est également appelé pool de mémoires tampons InnoDB sur Aurora MySQL et cache de tampon sur Aurora PostgreSQL.)

Dans l'éventualité peu probable d'une défaillance de la base de données, le cache de page reste en mémoire, ce qui maintient les pages de données actuelles à l'état pré-initialisé dans le cache de page au redémarrage de la base de données. Cette approche fournit un gain de performance, car les requêtes initiales n'ont pas besoin d'exécuter d'opérations d'E/S en lecture pour préparer le cache de page.

Pour Aurora MySQL, le comportement du cache de page lors du redémarrage et du basculement est le suivant :

• Versions antérieures à 2.10 : lorsque l'instance de base de données d'enregistreur redémarre, le cache de page de l'instance d'enregistreur survit, mais les instances de base de données de lecteur perdent leurs caches de pages.

• Version 2.10 et ultérieures : vous pouvez redémarrer l'instance d'enregistreur sans redémarrer les instances de lecteur.

  • Si les instances de lecteur ne redémarrent pas lors du redémarrage de l'instance d'enregistreur, elles ne perdent pas leurs caches de pages.

  • Si les instances de lecteur redémarrent lors du redémarrage de l'instance d'enregistreur, elles perdent leurs caches de pages.

• Lorsqu'une instance de lecteur redémarre, les caches de pages survivent à la fois sur les instances d'enregistreur et de lecteur.

• Lorsque le cluster de base de données bascule, l'effet est similaire au redémarrage d'une instance d'enregistreur. Sur la nouvelle instance d'enregistreur (auparavant l'instance de lecteur), le cache de page survit, mais sur l'instance de lecteur (auparavant l'instance d'enregistreur), le cache de page ne survit pas.

Pour Aurora PostgreSQL, vous pouvez utiliser la gestion du cache de cluster pour préserver le cache de page d'une instance de lecteur spécifique qui devient l'instance d'enregistreur après basculement. Pour plus d'informations, consultez Récupération rapide après basculement avec la gestion des caches de clusters pour Aurora PostgreSQL.

Reprise après un redémarrage imprévu

Aurora est conçu pour reprendre presque instantanément après un redémarrage imprévu, et continuer de servir les données de votre application sans le journal binaire. Aurora reprend de manière asynchrone sur des threads parallèles de telle sorte que votre base de données est ouverte et immédiatement accessible après un redémarrage imprévu.

Pour plus d’informations, consultez Tolérance aux pannes pour un cluster de base de données Aurora et Optimisations destinées à réduire le temps de redémarrage de la base de données.

Les points ci-dessous sont à prendre en considération pour la journalisation binaire et la reprise d'Aurora MySQL après un redémarrage imprévu :

• L'activation de la journalisation binaire dans Aurora affecte directement le délai de reprise après un redémarrage imprévu, car elle force l'instance de base de données à récupérer les journaux binaires.

• Le type de journalisation binaire utilisé affecte la taille et l'efficacité de la journalisation. Pour un même niveau d'activité de la base de données, certains formats consignent plus d'informations que d'autres dans les journaux binaires. Les valeurs suivantes du paramètre binlog_format entraînent des quantités différentes de données de journalisation :

  • ROW – Maximum de données de journalisation

  • STATEMENT – Minimum de données de journalisation

  • MIXED – Quantité modérée de données de journalisation qui représente généralement la meilleure option de performances et d'intégrité des données

  La quantité de données consignée dans les journaux binaires affecte la durée de récupération. Si une plus grande quantité de données est consignée dans les journaux binaires, l'instance de base de données doit traiter plus de données au cours de la récupération, ce qui augmente la durée de récupération.

• Pour réduire la charge de calcul et améliorer les temps de restauration grâce à la journalisation binaire, vous pouvez utiliser un journal binaire amélioré. Le journal binaire amélioré améliore le temps de restauration de la base de données jusqu'à 99 %. Pour plus d'informations, consultez Configuration du binlog amélioré.

• Aurora n'a pas besoin des journaux binaires pour répliquer les données au sein d'un cluster de base de données ou pour effectuer une point-in-time restauration (PITR).

• Si vous n'avez pas besoin du journal binaire pour la réplication externe (ou un flux de journal binaire externe), nous vous recommandons de définir le paramètre binlog_format sur OFF pour désactiver la journalisation binaire. Cela a pour effet de réduire le temps de récupération.

Pour plus d'informations sur la réplication et la journalisation binaire Aurora, consultez Réplication avec Amazon Aurora. Pour plus d'informations sur les implications des différents types de réplication MySQL, consultez Advantages and Disadvantages of Statement-Based and Row-Based Replication dans la documentation de MySQL.