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.
Gestion du cache du cluster
La mise en cache est l'une des fonctionnalités les plus importantes de toute base de données (DB) car elle permet de réduire le disque I/O. Les données les plus fréquemment consultées sont stockées dans une zone de mémoire appelée cache tampon. Lorsqu'une requête s'exécute fréquemment, elle extrait directement les données du cache plutôt que du disque. Cette opération est plus rapide et permet d'améliorer la capacité de mise à l'échelle et les performances des applications. Vous configurez la taille du cache PostgreSQL à l'aide du paramètre shared_buffers. Pour plus d'informations, veuillez consulter Memory
Après un basculement, la gestion du cache du cluster (CCM) dans Amazon Aurora PostgreSQL-Compatible Edition est conçue pour améliorer les performances de restauration des applications et des bases de données. Dans une situation de basculement classique sans CCM, vous pouvez constater une dégradation temporaire, mais conséquente, des performances. Cela est dû au fait que le cache du tampon est vide lorsque l'instance de base de données de basculement démarre. Un cache vide est également appelé cache passif. L'instance de base de données doit lire à partir du disque, ce qui est plus lent que la lecture à partir du cache.
Lorsque vous implémentez CCM, vous choisissez une instance de base de données de lecteur préférée, et CCM synchronise en permanence sa mémoire cache avec celle de l'instance de base de données principale ou d'enregistreur. En cas de basculement, l'instance de base de données de lecteur préférée est promue vers la nouvelle instance de base de données d'enregistreur. Parce qu'il possède déjà une mémoire cache, appelée cache actif, l'impact du basculement sur les performances de l'application est réduit.
Comment fonctionne la gestion du cache du cluster ?
Les instances de base de données de basculement sont situées dans des zones de disponibilité différentes de celles de l'instance de base de données d'enregistreur principale. L'instance de base de données de lecteur préférée est la cible de basculement prioritaire, qui est spécifiée en lui attribuant le niveau de priorité tier-0.
Note
La priorité du niveau de promotion est une valeur qui spécifie l’ordre dans lequel un lecteur Aurora est promu comme instance de base de données de l’enregistreur après un échec. Les valeurs valides sont comprises dans la plage 0–15, 0 étant la priorité la plus élevée et 15 la priorité la plus faible. Pour plus d'informations sur le niveau de promotion, veuillez consulter Tolérance aux pannes pour un cluster de base de données Aurora. La modification d'un niveau de promotion ne provoque pas d'interruption de service.
CCM synchronise le cache de l'instance de base de données d'enregistreur avec l'instance de base de données de lecteur préférée. L'instance de base de données de lecteur envoie l'ensemble des adresses de mémoire tampon actuellement mises en cache à l'instance de base de données d'enregistreur sous forme de filtre Bloom. Un filtre Bloom est une structure de données probabiliste et efficace en termes de mémoire qui est utilisée pour tester si un élément fait partie d'un ensemble. L'utilisation d'un filtre Bloom empêche l'instance de base de données de lecteur d'envoyer à plusieurs reprises les mêmes adresses de mémoire tampon à l'instance de base de données d'enregistreur. Lorsque l'instance de base de données d'enregistreur reçoit le filtre Bloom, elle compare les blocs de son cache de tampon et envoie les tampons fréquemment utilisés à l'instance de base de données de lecteur. Par défaut, une mémoire tampon est considérée comme fréquemment utilisée si son nombre d'utilisations est supérieur à trois.
Le schéma suivant montre comment CCM synchronise le cache de tampon de l'instance de base de données d'enregistreur avec l'instance de base de données de lecteur préférée.
Pour plus d'informations sur CCM, voir Restauration rapide après un basculement avec gestion du cache de cluster pour Aurora PostgreSQL (documentation Aurora) et Introduction à la gestion du cache de cluster Aurora PostgreSQL
Limitations
Les restrictions suivantes s'appliquent à la fonctionnalité CCM :
-
L'instance de base de données de lecteur doit avoir le même type de classe et la même taille d'instance que la base de données d'enregistreur, comme
r5.2xlargeoudb.r5.xlarge. -
CCM n'est pas prise en charge pour les clusters de base de données Aurora PostgreSQL qui font partie des bases de données globales Aurora.
Cas d'utilisation de la gestion des caches de clusters
Dans certains secteurs, tels que le commerce de détail, la banque et la finance, des retards de quelques millisecondes seulement peuvent entraîner des problèmes de performance des applications et engendrer une perte d'activité significative. Dans la mesure où CCM permet de rétablir les performances des applications et des bases de données en synchronisant en permanence le cache de tampon de l'instance de base de données principale avec l'instance de sauvegarde préférée, il peut contribuer à prévenir les pertes commerciales associées aux basculements.
