Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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
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 pages est également appelé pool de mémoire tampon InnoDB sur Aurora My SQL et cache de mémoire tampon sur Aurora SQL Postgre.)
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 pages lors du redémarrage et du basculement est le suivant :
-
Vous pouvez redémarrer l'instance du rédacteur sans redémarrer les instances du 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 désignée qui devient l'instance d'écriture après un basculement. Pour de plus amples informations, veuillez consulter 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.
Voici quelques considérations relatives à la journalisation binaire et à la reprise après un redémarrage imprévu sur Aurora My SQL :
-
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_formatentraî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 de plus amples informations, veuillez consulter Configuration d'un journal binaire amélioré pour Aurora MySQL.
-
Aurora n'a pas besoin des journaux binaires pour répliquer les données dans 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_formatsurOFFpour 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 SQL réplication My, consultez la section Avantages et inconvénients de la réplication basée sur des instructions et basée sur des lignes
