Surveillance d'une base de données globale Amazon Aurora - Amazon Aurora
Surveillance d'une base de données Aurora globale avec Performance InsightsSurveillance des bases de données mondiales d'Aurora grâce aux flux d'activité des bases de donnéesSurveillance des bases de données globales basées sur Aurora MySQLSurveillance des bases de données globales basées sur Aurora PostgreSQL

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.

Surveillance d'une base de données globale Amazon Aurora

Lorsque vous créez les clusters de bases de données Aurora qui composent votre base de données Aurora globale, vous pouvez choisir de nombreuses options qui vous permettent de surveiller leurs performances. Les options disponibles sont les suivantes :

  • Amazon RDS Performance Insights – Active le schéma de performance dans le moteur de base de données Aurora sous-jacent. Pour en savoir plus sur Performance Insights et les bases de données Aurora globales, consultez Surveillance d'une base de données Amazon Aurora globale avec Amazon RDS Performance Insights.

  • Surveillance améliorée – Génère des métriques pour l'utilisation des processus ou des threads sur le processeur. Pour en savoir plus sur la surveillance améliorée, consultez Surveillance des métriques du système d'exploitation à l'aide de la Surveillance améliorée.

  • Amazon CloudWatch Logs – Publie les types de journal spécifiés dans CloudWatch Logs. Les journaux d'erreurs sont publiés par défaut, mais vous pouvez choisir d'autres journaux spécifiques à votre moteur de base de données Aurora.

    • Pour les clusters de bases de données Aurora basés sur Aurora MySQL, vous pouvez exporter le journal d'audit, le journal général et le journal des requêtes lentes.

    • Pour les clusters de bases de données Aurora basés sur Aurora PostgreSQL, vous pouvez exporter le journal PostgreSQL.

  • Pour les bases de données globales basées sur Aurora MySQL, vous pouvez interroger des tables information_schema spécifiques pour vérifier l'état de votre base de données globale Aurora et de ses instances. Pour savoir comment procéder, veuillez consulter la section Surveillance des bases de données globales basées sur Aurora MySQL.

  • Pour les bases de données globales basées sur Aurora PostgreSQL, vous pouvez utiliser des fonctions spécifiques pour vérifier l'état de votre base de données globale Aurora et de ses instances. Pour savoir comment procéder, veuillez consulter la section Surveillance des bases de données globales basées sur Aurora PostgreSQL.

La capture d'écran suivante montre certaines des options disponibles sous l'onglet Surveillance d'un cluster de base de données Aurora principal dans une base de données Aurora globale.

Onglet Surveillance : liste déroulante Surveillance affichant les options CloudWatch, Surveillance améliorée, Liste des processus du système d'exploitation et Analyse des performances.

Pour plus d'informations, consultez Surveillance des métriques d'un cluster de bases de données Amazon Aurora.

Surveillance d'une base de données Amazon Aurora globale avec Amazon RDS Performance Insights

Vous pouvez utiliser Amazon RDS Performance Insights pour vos des bases de données Aurora globales. Vous activez cette fonctionnalité à l'échelle individuelle, pour chaque cluster de base de données Aurora de votre base de données Aurora globale. Pour ce faire, Sélectionnez Activer Performance Insights dans la section Configuration supplémentaire de la page Créer une base de données. Vous pouvez également modifier vos clusters de bases de données Aurora pour utiliser cette fonctionnalité une fois qu'ils sont opérationnels. Vous pouvez activer ou désactiver Performance Insights pour chaque cluster qui fait partie de la base de données Aurora globale.

Les rapports créés par Performance Insights s'appliquent à chaque cluster de la base de données globale. Lorsque vous ajoutez une nouvelle Région AWS secondaire à une base de données Aurora globale qui utilise déjà Performance Insights, vous devez vous assurer d'activer cette option dans le cluster nouvellement ajouté. Elle n'hérite pas du paramètre Performance Insights de la base de données globale existante.

Vous pouvez passer d'une Régions AWS à une autre sur la page Performance Insights pour une instance de base de données qui est attachée à une base de données globale. Cependant, il se peut que vous ne voyiez pas les informations relatives aux performances immédiatement après avoir basculé d'une Régions AWS à une autre. Même si les instances de base de données peuvent avoir des noms identiques dans chaque Région AWS, l'URL Performance Insights associée est différente pour chaque instance de base de données. Après avoir basculé d'une Régions AWS à une autre, choisissez le nom de l'instance de base de données dans le panneau de navigation Performance Insights.

Pour les instances de base de données associées à une base de données globale, les facteurs affectant les performances peuvent être différents dans chaque Région AWS. Par exemple, les instances de base de données de chaque Région AWS peuvent avoir une capacité différente.

Pour plus d'informations sur l'utilisation de Performance Insights, consultez Surveillance de la charge de la base de données avec Performance Insights sur .

Surveillance des bases de données mondiales d'Aurora grâce aux flux d'activité des bases de données

En utilisant la fonction de flux d'activité de base de données, vous pouvez surveiller et définir des alarmes pour auditer l'activité dans les clusters de bases de données de votre base de données globale. Vous démarrez un flux d'activité de base de données sur chaque cluster de base de données séparément. Chaque cluster fournit des données d'audit à son propre flux Kinesis au sein de sa propre Région AWS. Pour plus d'informations, consultez Surveillance d'Amazon Aurora à l'aide des flux d'activité de base de données.

Surveillance des bases de données globales basées sur Aurora MySQL

Pour consulter l'état d'une base de données globale basée sur Aurora MySQL, interrogez les tables information_schema.aurora_global_db_status et information_schema.aurora_global_db_instance_status.

Note

Les tables information_schema.aurora_global_db_status et information_schema.aurora_global_db_instance_status ne sont disponibles qu'avec Aurora MySQL 3.04.0 et versions ultérieures.

Pour surveiller une base de données globale basée sur Aurora MySQL

  1. Connectez-vous au point de terminaison du cluster principal de la base de données globale à l'aide d'un client MySQL. Pour plus d'informations sur la connexion, veuillez consulter Connexion à une base de données Amazon Aurora globale.

  2. Interrogez la table information_schema.aurora_global_db_status dans une commande mysql pour répertorier les volumes principal et secondaire. Cette requête renvoie les temps de retard des clusters de bases de données secondaires de la base de données globale, comme dans l'exemple suivant.

    mysql> select * from information_schema.aurora_global_db_status;
    AWS_REGION | HIGHEST_LSN_WRITTEN | DURABILITY_LAG_IN_MILLISECONDS | RPO_LAG_IN_MILLISECONDS | LAST_LAG_CALCULATION_TIMESTAMP | OLDEST_READ_VIEW_TRX_ID
-----------+---------------------+--------------------------------+------------------------+---------------------------------+------------------------
us-east-1  |           183537946 |                            0   |                      0 |  1970-01-01 00:00:00.000000     |               0
us-west-2  |           183537944 |                            428 |                      0 |  2023-02-18 01:26:41.925000     |               20806982
(2 rows)

    La sortie inclut une ligne pour chaque cluster de base de données de la base de données globale contenant les colonnes suivantes :

    • AWS_REGION : Région AWS dans laquelle se trouve ce cluster de base de données. Pour obtenir des tableaux répertoriant les Régions AWS par moteur, veuillez consulter Régions et zones de disponibilité.

    • HIGHEST_LSN_WRITTEN : numéro de séquence de journal (LSN) le plus élevé actuellement écrit sur ce cluster de base de données.

      Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu'un LSN plus grand représente une transaction ultérieure.

    • DURABILITY_LAG_IN_MILLISECONDS : différence dans les valeurs d'horodatage entre HIGHEST_LSN_WRITTEN sur un cluster de base de données secondaire et HIGHEST_LSN_WRITTEN sur le cluster de base de données principal. Cette valeur est toujours égale à 0 sur le cluster de base de données principal de la base de données globale Aurora.

    • RPO_LAG_IN_MILLISECONDS : retard de l'objectif de point de reprise (RPO). Le retard RPO correspond au temps nécessaire au stockage de la transaction utilisateur COMMIT la plus récente sur un cluster de base de données secondaire, après qu'elle a été stockée sur le cluster de base de données principal de la base de données globale Aurora. Cette valeur est toujours égale à 0 sur le cluster de base de données principal de la base de données globale Aurora.

      En termes simples, cette métrique calcule l'objectif de point de reprise pour chaque cluster de base de données Aurora MySQL dans la base de données globale Aurora, c'est-à-dire la quantité de données qui risque d'être perdue en cas de panne. Comme pour la latence, le RPO est mesuré dans le temps.

    • LAST_LAG_CALCULATION_TIMESTAMP : horodatage qui indique quand a eu lieu le dernier calcul des valeurs pour DURABILITY_LAG_IN_MILLISECONDS et RPO_LAG_IN_MILLISECONDS. Une valeur temporelle telle que 1970-01-01 00:00:00+00 signifie qu'il s'agit du cluster de base de données principal.

    • OLDEST_READ_VIEW_TRX_ID : ID de la transaction la plus ancienne vers laquelle l'instance de base de données d'enregistreur peut effectuer une purge.

  3. Interrogez la table information_schema.aurora_global_db_instance_status pour répertorier toutes les instances de base de données secondaires pour le cluster de base de données principal et les clusters de bases de données secondaires.

    mysql> select * from information_schema.aurora_global_db_instance_status;
    SERVER_ID            |              SESSION_ID              | AWS_REGION | DURABLE_LSN | HIGHEST_LSN_RECEIVED | OLDEST_READ_VIEW_TRX_ID | OLDEST_READ_VIEW_LSN | VISIBILITY_LAG_IN_MSEC
---------------------+--------------------------------------+------------+-------------+----------------------+-------------------------+----------------------+------------------------
ams-gdb-primary-i2   | MASTER_SESSION_ID                    | us-east-1  | 183537698   |                    0 |                       0 |                    0 |                      0 
ams-gdb-secondary-i1 | cc43165b-bdc6-4651-abbf-4f74f08bf931 | us-west-2  | 183537689   |            183537692 |                20806928 |            183537682 |                      0 
ams-gdb-secondary-i2 | 53303ff0-70b5-411f-bc86-28d7a53f8c19 | us-west-2  | 183537689   |            183537692 |                20806928 |            183537682 |                    677 
ams-gdb-primary-i1   | 5af1e20f-43db-421f-9f0d-2b92774c7d02 | us-east-1  | 183537697   |            183537698 |                20806930 |            183537691 |                     21 
(4 rows)

    La sortie inclut une ligne pour chaque instance de base de données de la base de données globale contenant les colonnes suivantes :

    • SERVER_ID : identifiant du serveur pour l'instance de base de données.

    • SESSION_ID : identifiant unique pour la session en cours. La valeur MASTER_SESSION_ID identifie l'instance de base de données d'enregistreur (principale).

    • AWS_REGION : Région AWS dans laquelle se trouve cette instance de base de données. Pour obtenir des tableaux répertoriant les Régions AWS par moteur, veuillez consulter Régions et zones de disponibilité.

    • DURABLE_LSN : LSN rendu durable dans le stockage.

    • HIGHEST_LSN_RECEIVED : LSN le plus élevé reçu par l'instance de base de données depuis l'instance de base de données d'enregistreur.

    • OLDEST_READ_VIEW_TRX_ID : ID de la transaction la plus ancienne vers laquelle l'instance de base de données d'enregistreur peut effectuer une purge.

    • OLDEST_READ_VIEW_LSN : LSN le plus ancien utilisé par l'instance de base de données pour lire à partir du stockage.

    • VISIBILITY_LAG_IN_MSEC : pour les lecteurs dans le cluster de base de données principal, retard accumulé par cette instance de base de données par rapport à l'instance de base de données d'enregistreur en millisecondes. Pour les lecteurs dans un cluster de base de données secondaire, retard accumulé par cette instance de base de données par rapport au volume secondaire en millisecondes.

Pour voir comment ces valeurs changent au fil du temps, examinez le bloc de transaction suivant où une insertion de table prend une heure.

mysql> BEGIN;
mysql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
mysql> COMMIT;

Dans certains cas, une déconnexion réseau peut se produire entre le cluster de base de données principal et le cluster de base de données secondaire après l'instruction BEGIN. Si tel est le cas, la valeur de DURABILITY_LAG_IN_MILLISECONDS du cluster de base de données secondaire commence à augmenter. À la fin de l'instruction INSERT, la valeur de DURABILITY_LAG_IN_MILLISECONDS est de 1 heure. Toutefois, la valeur de RPO_LAG_IN_MILLISECONDS est 0, car toutes les données utilisateur validées entre le cluster de base de données principal et le cluster de base de données secondaire sont encore les mêmes. Dès que l'instruction COMMIT se termine, la valeur de RPO_LAG_IN_MILLISECONDS augmente.

Surveillance des bases de données globales basées sur Aurora PostgreSQL

Pour voir l'état d'une base de données globale basée sur Aurora PostgreSQL, utilisez les fonctions aurora_global_db_status et aurora_global_db_instance_status.

Note

Seul Aurora PostgreSQL prend en charge les fonctions aurora_global_db_status et aurora_global_db_instance_status.

Pour surveiller une base de données globale basée sur Aurora PostgreSQL

  1. Connectez-vous au point de terminaison principal de cluster de base de données globale à l'aide d'un utilitaire PostgreSQL tel que psql. Pour plus d'informations sur la connexion, veuillez consulter Connexion à une base de données Amazon Aurora globale.

  2. Utilisez la fonction aurora_global_db_status d'une commande psql pour répertorier les volumes primaire et secondaire. Ceci affiche les temps de latence des clusters de base de données secondaires de la base de données globale.

    postgres=> select * from aurora_global_db_status();
    aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time  | feedback_epoch | feedback_xmin
------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
us-east-1  |         93763984222 |                     -1 |              -1 | 1970-01-01 00:00:00+00     |              0 |             0
us-west-2  |         93763984222 |                    900 |            1090 | 2020-05-12 22:49:14.328+00 |              2 |    3315479243
(2 rows)

    La sortie inclut une ligne pour chaque cluster de base de données de la base de données globale contenant les colonnes suivantes :

    • aws_region – Région AWS dans laquelle se trouve ce cluster de base de données. Pour obtenir des tableaux répertoriant les Régions AWS par moteur, veuillez consulter Régions et zones de disponibilité.

    • highest_lsn_written – Numéro de séquence de journal (LSN) le plus élevé actuellement écrit sur ce cluster de base de données.

      Un numéro de séquence de journal (LSN) est un numéro séquentiel unique qui identifie un enregistrement dans le journal des transactions de la base de données. Les LSN sont classés de telle sorte qu'un LSN plus grand représente une transaction ultérieure.

    • durability_lag_in_msec – Différence d'horodatage entre le numéro de séquence de journal le plus élevé écrit sur un cluster de base de données secondaire (highest_lsn_written) et le highest_lsn_written sur le cluster de base de données principal.

    • rpo_lag_in_msec – Le retard de l'objectif de point de récupération (RPO). Cette latence correspond à la différence de temps entre la validation de transaction utilisateur la plus récente stockée sur un cluster de base de données secondaire et la validation de transaction utilisateur la plus récente stockée sur le cluster de base de données principal.

    • last_lag_calculation_time – Horodatage lors du dernier calcul des valeurs pour durability_lag_in_msec et rpo_lag_in_msec.

    • feedback_epoch – Époque utilisée par un cluster de base de données secondaire lorsqu'il génère des informations de veille à chaud.

      On appelle veille à chaud le moment où un cluster de base de données peut se connecter et interroger pendant que le serveur est en mode de récupération ou veille. Les commentaires de veille à chaud sont des informations sur le cluster de base de données lorsqu'il est en veille à chaud. Pour de plus amples informations, veuillez consulter la documentation PostgreSQL sur Veille à chaud.

    • feedback_xmin – ID de transaction actif minimum (le plus ancien) utilisé par un cluster de base de données secondaire.

  3. Utilisez la fonction aurora_global_db_instance_status pour répertorier toutes les instances de base de données secondaires pour le cluster de base de données principal et les clusters de base de données secondaires.

    postgres=> select * from aurora_global_db_instance_status();
    server_id                                   |              session_id              | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
--------------------------------------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------
apg-global-db-rpo-mammothrw-elephantro-1-n1 | MASTER_SESSION_ID                    | us-east-1  | 93763985102 |                  |                |               |                      |
apg-global-db-rpo-mammothrw-elephantro-1-n2 | f38430cf-6576-479a-b296-dc06b1b1964a | us-east-1  | 93763985099 |      93763985102 |              2 |    3315479243 |          93763985095 |                     10
apg-global-db-rpo-elephantro-mammothrw-n1   | 0d9f1d98-04ad-4aa4-8fdd-e08674cbbbfe | us-west-2  | 93763985095 |      93763985099 |              2 |    3315479243 |          93763985089 |                   1017
(3 rows)

    La sortie inclut une ligne pour chaque instance de base de données de la base de données globale contenant les colonnes suivantes :

    • server_id – Identificateur du serveur pour l'instance de base de données.

    • session_id – Identificateur unique pour la session en cours.

    • aws_region – Région AWS dans laquelle se trouve cette instance de base de données. Pour obtenir des tableaux répertoriant les Régions AWS par moteur, veuillez consulter Régions et zones de disponibilité.

    • durable_lsn – Le LSN rendu durable dans le stockage.

    • highest_lsn_rcvd – LSN le plus élevé reçu par l'instance de base de données depuis l'instance de base de données de l'enregistreur.

    • feedback_epoch – L'époque utilisée par l'instance de base de données lorsqu'elle génère des informations de veille à chaud.

      On appelle veille à chaud le moment où une instance de base de données peut se connecter et interroger pendant que le serveur est en mode de récupération ou veille. Les commentaires de veille à chaud sont des informations sur l'instance de base de données lorsqu'elle est en veille à chaud. Pour de plus amples informations, veuillez consulter la documentation PostgreSQL sur Veille à chaud.

    • feedback_xmin – ID de transaction actif minimum (le plus ancien) utilisé par l'instance de base de données.

    • oldest_read_view_lsn – Le LSN le plus ancien utilisé par l'instance de base de données pour lire à partir du stockage.

    • visibility_lag_in_msec – Quelle est la latence de cette instance de base de données par rapport à l'instance de base de données rédacteur.

Pour voir comment ces valeurs changent au fil du temps, examinez le bloc de transaction suivant où une insertion de table prend une heure.

psql> BEGIN;
psql> INSERT INTO table1 SELECT Large_Data_That_Takes_1_Hr_To_Insert;
psql> COMMIT;

Dans certains cas, une déconnexion réseau peut se produire entre le cluster de base de données principal et le cluster de base de données secondaire après l'instruction BEGIN. Si c'est le cas, la valeur durability_lag_in_msec du cluster de base de données secondaire commence à augmenter. À la fin de l'instruction INSERT, la valeur durability_lag_in_msec est 1 heure. Toutefois, la valeur rpo_lag_in_msec est 0, car toutes les données utilisateur validées entre le cluster de base de données principal et le cluster de base de données secondaire sont encore les mêmes. Dès que l'instruction COMMIT est terminée, la valeur rpo_lag_in_msec augmente.