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.
Récupération rapide après basculement avec la gestion des caches de clusters pour Aurora PostgreSQL
Pour procéder à une récupération rapide de l'instance de base de données de l'enregistreur dans vos clusters Aurora PostgreSQL en cas de basculement, utilisez la gestion des caches de clusters pour Amazon Aurora PostgreSQL. La gestion des caches de clusters préserve les performances d'une application en cas de basculement.
Dans une situation de basculement classique, vous pouvez constater une dégradation temporaire, mais conséquente, des performances après un basculement. Cela est dû au fait que le cache des tampons est vide lorsque l'instance de base de données démarre. Un cache vide est également appelé cache passif. Un cache passif nuit aux performances, car l'instance de base de données doit lire sur le disque qui est ralenti, au lieu de tirer parti des valeurs stockées dans le cache de tampons.
La gestion des caches de clusters vous permet de définir une instance de base de données d'un lecteur spécifique en tant que cible de basculement. Elle garantit que les données présentes dans le cache du lecteur désigné restent synchronisées avec les données présentes dans le cache de l'instance de base de données de l'enregistreur. Le cache du lecteur désigné comportant des valeurs prérenseignées s'appelle un cache actif. En cas de basculement, le lecteur désigné utilise les valeurs présentes dans son cache actif dès qu'il est promu comme instance de base de données du nouvel enregistreur. Grâce à cette approche, votre application bénéficie de performances de récupération largement supérieures.
La gestion du cache de cluster nécessite que l'instance de lecteur désignée ait le même type et la même taille de classe d'instance (db.r5.2xlarge ou db.r5.xlarge, par exemple) que le scripteur. Gardez cela à l'esprit lors de la création de clusters de base de données Aurora PostgreSQL afin que vos clusters puissent récupérer lors d'un basculement. Pour obtenir une liste des types et des tailles de classes d'instance, consultez Spécifications matérielles pour les classes d'instance de base de données pour Aurora.
Note
La gestion des caches de clusters 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. Il est recommandé de ne pas exécuter de charge de travail sur le lecteur de niveau 0 désigné.
Table des matières
Configuration de la gestion des caches de clusters
Pour configurer la gestion du cache de cluster, procédez comme suit dans l'ordre.
Rubriques
Note
Attendez au moins 1 minute après avoir effectué ces étapes pour que la gestion des caches de clusters soit pleinement opérationnelle.
Activation de la gestion des caches de clusters
Pour activer la gestion du cache de cluster, procédez comme suit.
Pour activer la gestion des caches de clusters
-
Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le volet de navigation, choisissez Groupes de paramètres.
-
Dans la liste, choisissez le groupe de paramètres pour votre cluster de base de données Aurora PostgreSQL.
Le cluster de base de données doit utiliser un groupe de paramètres autre que le groupe par défaut, car vous ne pouvez pas modifier les valeurs d'un groupe de paramètres par défaut.
-
Sous Parameter group actions (Actions de groupe de paramètres), choisissez Edit (Modifier).
-
Définissez la valeur du paramètre de cluster
apg_ccm_enabledsur 1. -
Sélectionnez Save Changes.
Pour activer la gestion des caches de clusters pour un cluster de base de données Aurora PostgreSQL, utilisez la commande modify-db-cluster-parameter-group de la AWS CLI avec les paramètres requis suivants :
-
--db-cluster-parameter-group-name -
--parameters
Exemple
Pour LinuxmacOS, ou Unix :
aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-namemy-db-cluster-parameter-group\ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
Dans Windows :
aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-namemy-db-cluster-parameter-group^ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
Définition de la priorité du niveau de promotion pour l'instance de base de données de l'enregistreur
Pour la gestion du cache de cluster, assurez-vous que la priorité de promotion est de niveau 0 pour l'instance de base de données de l'enregistreur du cluster de base de données Aurora PostgreSQL. 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.
Pour définir la priorité de la promotion pour l'instance de base de données de l'enregistreur sur tier-0 (niveau 0)
Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/
. -
Dans la panneau de navigation, choisissez Databases (Bases de données).
-
Choisissez l'instance de base de données Writer (Enregistreur) du cluster de base de données Aurora PostgreSQL.
-
Sélectionnez Modify. La page Modifier l'instance de base de données s'affiche.
-
Dans le panneau Configuration supplémentaire, choisissez tier-0 (niveau 0) pour Priorité de basculement.
-
Choisissez Continuer et vérifiez le récapitulatif des modifications.
-
Pour appliquer les modifications immédiatement après les avoir enregistrées, choisissez Appliquer immédiatement.
-
Choisissez Modifier l'instance de base de données pour enregistrer vos modifications.
Pour définir la priorité du niveau de promotion sur 0 pour l'instance de base de données Writer à l'aide deAWS CLI, appelez la modify-db-instancecommande avec les paramètres requis suivants :
-
--db-instance-identifier -
--promotion-tier -
--apply-immediately
Exemple
Pour LinuxmacOS, ou Unix :
aws rds modify-db-instance \ --db-instance-identifierwriter-db-instance\ --promotion-tier 0 \ --apply-immediately
Dans Windows :
aws rds modify-db-instance ^ --db-instance-identifierwriter-db-instance^ ---promotion-tier 0 ^ --apply-immediately
Définition de la priorité du niveau de promotion pour une instance de base de données du lecteur
Vous ne devez définir qu'une seule instance de base de données de lecteur pour la gestion du cache du cluster. Pour cela, choisissez un lecteur dans le cluster Aurora PostgreSQL ayant les mêmes taille et classe d'instance que l'instance de base de données du scripteur. Par exemple, si le scripteur utilise db.r5.xlarge, choisissez un lecteur utilisant le même type et la même taille de classe d'instance. Définissez ensuite la priorité du niveau de promotion sur 0.
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 définir la priorité de la promotion de l'instance de base de données du lecteur sur tier-0 (niveau 0)
Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/
. -
Dans la panneau de navigation, choisissez Databases (Bases de données).
-
Pour cela, choisissez une instance de base de données du lecteur du cluster de base de données Aurora PostgreSQL ayant la même classe d'instance que l'instance de base de données de l'enregistreur.
-
Sélectionnez Modify. La page Modifier l'instance de base de données s'affiche.
-
Dans le panneau Configuration supplémentaire, choisissez tier-0 (niveau 0) pour Priorité de basculement.
-
Choisissez Continuer et vérifiez le récapitulatif des modifications.
-
Pour appliquer les modifications immédiatement après les avoir enregistrées, choisissez Appliquer immédiatement.
-
Choisissez Modifier l'instance de base de données pour enregistrer vos modifications.
Pour définir la priorité du niveau de promotion sur 0 pour l'instance de base de données du lecteur à l'aide deAWS CLI, appelez la modify-db-instancecommande avec les paramètres requis suivants :
-
--db-instance-identifier -
--promotion-tier -
--apply-immediately
Exemple
Pour LinuxmacOS, ou Unix :
aws rds modify-db-instance \ --db-instance-identifierreader-db-instance\ --promotion-tier 0 \ --apply-immediately
Dans Windows :
aws rds modify-db-instance ^ --db-instance-identifierreader-db-instance^ ---promotion-tier 0 ^ --apply-immediately
Surveillance du cache de tampons
Une fois la gestion des caches de clusters définie, vous pouvez surveiller l'état de la synchronisation entre le cache de tampon des instances de bases de données d'enregistreur et le cache de tampon actif du lecteur désigné. Pour examiner le contenu du cache de tampons sur l'instance de base de données de l'enregistreur et sur l'instance de base de données du lecteur désigné, utilisez le module pg_buffercache PostgreSQL. Pour plus d'informations, veuillez consulter la documentation sur PostgreSQLpg_buffercache
Utilisation de la fonction aurora_ccm_status
La gestion des caches de clusters fournit également la fonction aurora_ccm_status. Utilisez la fonction aurora_ccm_status sur l'instance de base de données de l'enregistreur pour obtenir les informations suivantes sur la progression de l'activation du cache sur le lecteur désigné :
-
buffers_sent_last_minute– Nombre de tampons envoyés au lecteur désigné au cours de la dernière minute. buffers_found_last_minute: nombre de tampons fréquemment consultés, identifiés au cours de la dernière minute.-
buffers_sent_last_scan– Nombre de tampons envoyés au lecteur désigné au cours de la dernière analyse terminée du cache du tampon. -
buffers_found_last_scan– Nombre de tampons identifiés comme fréquemment consultés et ayant dû être envoyés au cours de la dernière analyse terminée du cache du tampon. Les tampons déjà mis en cache sur le lecteur désigné ne sont pas envoyés. -
buffers_sent_current_scan– Nombre de tampons envoyés jusqu'à maintenant au cours de l'analyse actuelle. -
buffers_found_current_scan– Nombre de tampons identifiés comme fréquemment consultés au cours de l'analyse actuelle. -
current_scan_progress– Nombre de tampons visités jusqu'à maintenant au cours de l'analyse actuelle.
L'exemple suivant illustre l'utilisation de la fonction aurora_ccm_status pour convertir une partie du résultat en débit d'activation et en pourcentage d'activation.
SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent FROM aurora_ccm_status();
Résolution des problèmes de configuration du CCM
Lorsque vous activez le paramètre de apg_ccm_enabled cluster, la gestion du cache de cluster est automatiquement activée au niveau de l'instance sur l'instance de base de données du rédacteur et d'une instance de base de données du lecteur sur le cluster de base de données Aurora PostgreSQL. Les instances du rédacteur et du lecteur doivent utiliser le même type et la même taille de classe d'instance. La priorité de leur niveau de promotion est définie sur0. Les autres instances de lecteur du cluster de base de données doivent avoir un niveau de promotion différent de zéro et la gestion du cache du cluster est désactivée pour ces instances.
Les raisons suivantes peuvent entraîner des problèmes de configuration et désactiver la gestion du cache du cluster :
Lorsqu'aucune instance de base de données à lecteur unique n'est définie sur le niveau de promotion 0.
Lorsque l'instance de base de données Writer n'est pas définie sur le niveau de promotion 0.
Lorsque plusieurs instances de base de données de lecteur sont définies sur le niveau de promotion 0.
Lorsque le rédacteur et un lecteur, les instances de base de données avec le niveau de promotion 0 n'ont pas la même taille d'instance.
