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.

Configuration de la gestion des caches de clusters

Pour configurer la gestion du cache de cluster, procédez comme suit dans l'ordre.

Activation de la gestion des caches de clusters

Pour activer la gestion du cache de cluster, procédez comme suit.

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name my-db-cluster-parameter-group \
    --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

aws rds modify-db-cluster-parameter-group ^
    --db-cluster-parameter-group-name my-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.

aws rds modify-db-instance \
    --db-instance-identifier writer-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier writer-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.

aws rds modify-db-instance \
    --db-instance-identifier reader-db-instance \
    --promotion-tier 0 \
    --apply-immediately

aws rds modify-db-instance ^
    --db-instance-identifier reader-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é :

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 :