Monitoraggio di un database globale Amazon Aurora - Amazon Aurora
Monitoraggio di un database globale Aurora con Performance InsightsMonitoraggio dei database globali Aurora con i flussi di attività di databaseMonitoraggio dei database globali basati su Aurora MySQLMonitoraggio dei database globali Aurora basati su PostgreSQL

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Monitoraggio di un database globale Amazon Aurora

Quando si creano i cluster di database Aurora che costituiscono il database globale Aurora, è possibile scegliere molte opzioni che consentono di monitorare le prestazioni del cluster di database. Queste opzioni includono:

  • Amazon RDS Performance Insights – Supporta lo schema delle prestazioni nel motore di database Aurora sottostante. Per ulteriori informazioni su Performance Insights e database globali Aurora, consulta Monitoraggio di un database globale Amazon Aurora con Amazon RDS Performance Insights.

  • Monitoraggio avanzato – Genera parametri per l'utilizzo di processi o thread sulla CPU. Per ulteriori informazioni sul monitoraggio avanzato, consulta Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato.

  • Amazon CloudWatch Logs – Pubblica i tipi di log specificati in CloudWatch Logs. I log degli errori vengono pubblicati per impostazione predefinita, ma è possibile scegliere altri log specifici per il motore di database Aurora.

    • Per i cluster di database Aurora basati su Aurora MySQL è possibile esportare il log di controllo, il log generale e il log delle query lente.

    • Per i cluster database Aurora basati su Aurora PostgreSQL, puoi esportare il log PostgreSQL.

  • Per i database globali basati su Aurora MySQL, è possibile eseguire query su tabelle information_schema specifiche per verificare lo stato del database globale Aurora e delle relative istanze. Per scoprire come fare, consulta Monitoraggio dei database globali basati su Aurora MySQL.

  • Per i database globali basati su Aurora PostgreSQL, è possibile utilizzare funzioni specifiche per verificare lo stato del database globale Aurora e delle relative istanze. Per scoprire come fare, consulta Monitoraggio dei database globali Aurora basati su PostgreSQL.

La seguente schermata mostra alcune delle opzioni disponibili nella scheda Monitoraggio di un cluster di database Aurora primario in un database globale Aurora.

Scheda Monitoraggio: menu a discesa Monitoraggio che mostra le opzioni CloudWatch, Monitoraggio avanzato, Elenco dei processi del sistema operativo e Performance Insights.

Per ulteriori informazioni, consulta Monitoraggio dei parametri in un cluster di database Amazon Aurora.

Monitoraggio di un database globale Amazon Aurora con Amazon RDS Performance Insights

È possibile utilizzare Amazon RDS Performance Insights per i database globali Aurora. È possibile abilitare questa funzionalità singolarmente, per ogni cluster di database Aurora nel database globale Aurora. A tale scopo, scegliere Enable Performance Insights (Abilita Performance Insights) nella sezione Additional configuration (Configurazioni aggiuntive) della pagina Crea database. In alternativa, una volta operativi, è possibile modificare i cluster di database Aurora per utilizzare questa funzionalità. È possibile abilitare o disattivare Performance Insights per ciascun cluster che fa parte del database globale Aurora.

I report creati da Performance Insights si applicano a ciascun cluster del database globale. Quando si aggiunge una nuova Regione AWS secondaria a un database globale Aurora che sta già utilizzando Performance Insights, sarà necessario abilitare Performance Insights nel cluster appena aggiunto. Non eredita l'impostazione Performance Insights dal database globale esistente.

È possibile cambiare le Regioni AWS mentre si visualizza la pagina Performance Insights per un'istanza database allegata a un database globale. Tuttavia, potreste non vedere le informazioni sulle prestazioni subito dopo aver cambiato Regioni AWS. Anche se le istanze database potrebbero avere gli stessi nomi in ciascuna Regione AWS, l'URL Performance Insights associato è diverso per ogni istanza database. Dopo aver cambiato Regioni AWS, scegliere di nuovo il nome dell'istanza database nel riquadro di navigazione Performance Insights.

Per le istanze database associate a un database globale, i fattori che influiscono sulle prestazioni potrebbero essere diversi in ciascuna Regione AWS. Ad esempio, le istanze database in ciascuna Regione AWS potrebbero avere una diversa capacità.

Per ulteriori informazioni sull'utilizzo di Performance Insights, consulta Monitoraggio del carico DB con Performance Insights su Amazon Aurora.

Monitoraggio dei database globali Aurora con i flussi di attività di database

Con i flussi di attività del database è possibile monitorare e impostare gli allarmi per l'attività di audit nei cluster database del database globale. Avvia un flusso di attività del database su ciascun cluster database separatamente. Ciascun cluster fornisce i dati di audit al proprio flusso Kinesis all'interno della propria Regione AWS. Per ulteriori informazioni, consulta Monitoraggio di Amazon Aurora tramite i flussi di attività del database.

Monitoraggio dei database globali basati su Aurora MySQL

Per visualizzare lo stato di un database globale basato su Aurora MySQL, occorre eseguire query delle tabelle information_schema.aurora_global_db_status e information_schema.aurora_global_db_instance_status.

Nota

Le tabelle information_schema.aurora_global_db_status e information_schema.aurora_global_db_instance_status sono disponibili solo con i database globali Aurora MySQL 3.04.0 e versioni successive.

Per monitorare un database globale basato su Aurora MySQL

  1. Esegui la connessione all'endpoint del cluster primario del database globale utilizzando un client MySQL. Per ulteriori informazioni su come connettersi, consulta Connessione a un database globale Amazon Aurora.

  2. Esegui la query sulla tabella information_schema.aurora_global_db_status in un comando mysql per elencare i volumi primari e secondari. Questa query restituisce i tempi di ritardo dei cluster database secondari del database globale, come nell'esempio seguente.

    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)

    L'output include una riga per ogni cluster DB del database globale contenente le seguenti colonne:

    • AWS_REGION: la Regione AWS in cui si trova questo cluster database. Per le tabelle che elencano le Regioni AWS in base al motore, consulta Regioni e zone di disponibilità.

    • HIGHEST_LSN_WRITTEN: il numero di sequenza di log più alto (LSN) attualmente scritto in questo cluster database.

      Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.

    • DURABILITY_LAG_IN_MILLISECONDS: la differenza nei valori di timestamp tra il parametro HIGHEST_LSN_WRITTEN su un cluster database secondario e il parametro HIGHEST_LSN_WRITTEN sul cluster database primario. Questo valore è sempre 0 sul cluster database primario del database globale Aurora.

    • RPO_LAG_IN_MILLISECONDS: il ritardo dell'obiettivo del punto di ripristino (RPO). Il ritardo dell'obiettivo del punto di ripristino (RPO) è il tempo necessario per memorizzare il COMMIT delle transazioni utente più recenti dopo la sua memorizzazione nel cluster di database primario del database globale Aurora. Questo valore è sempre 0 sul cluster database primario del database globale Aurora.

      In sintesi, questo parametro calcola l'obiettivo del punto di ripristino per ciascun cluster database Aurora MySQL nel database globale Aurora, ovvero quanti dati potrebbero andare perduti in caso di interruzione. Come per il ritardo, l'obiettivo del punto di ripristino (RPO) viene misurato nel tempo.

    • LAST_LAG_CALCULATION_TIMESTAMP: il timestamp che specifica l'ultima volta in cui i valori stati calcolati per DURABILITY_LAG_IN_MILLISECONDS e RPO_LAG_IN_MILLISECONDS. Il valore temporale 1970-01-01 00:00:00+00 indica che questo è il cluster di database primario.

    • OLDEST_READ_VIEW_TRX_ID: l'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura.

  3. Esegui una query sulla tabella information_schema.aurora_global_db_instance_status per elencare tutte le istanze database secondarie per il cluster database primario e i cluster database secondari.

    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)

    L'output include una riga per ogni istanza DB del database globale contenente le colonne seguenti:

    • SERVER_ID: identificatore del server per l'istanza database.

    • SESSION_ID: un identificatore univoco per la sessione corrente. Il valore di MASTER_SESSION_ID identifica l'istanza database di lettura (primaria).

    • AWS_REGION: la Regione AWS in cui si trova questa istanza database. Per le tabelle che elencano le Regioni AWS in base al motore, consulta Regioni e zone di disponibilità.

    • DURABLE_LSN: l'LSN è stato reso durevole nello storage.

    • HIGHEST_LSN_RECEIVED: l'LSN più alto ricevuto dall'istanza database dall'istanza database di scrittura.

    • OLDEST_READ_VIEW_TRX_ID: l'ID della transazione più vecchia che può essere rimossa dall'istanza database di scrittura.

    • OLDEST_READ_VIEW_LSN: l'LSN più vecchio utilizzato dall'istanza database per leggere dallo storage.

    • VISIBILITY_LAG_IN_MSEC: per le istanze di lettura nel cluster database primario, il ritardo in millisecondi di questa istanza database rispetto all'istanza database di scrittura. Per istanze di lettura in un cluster database secondario, il ritardo in millisecondi di questa istanza database rispetto al volume secondario.

Per vedere come questi valori cambiano nel tempo, considerare il seguente blocco di transazioni in cui un inserimento di tabella richiede un'ora:

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

In alcuni casi, potrebbe esserci una disconnessione di rete tra il cluster DB primario e il cluster DB secondario dopo l'istruzione BEGIN. In tal caso, il valore DURABILITY_LAG_IN_MILLISECONDS del cluster database secondario inizia ad aumentare. Alla fine dell'istruzione INSERT, il valore DURABILITY_LAG_IN_MILLISECONDS è di 1 ora. Tuttavia, il valore RPO_LAG_IN_MILLISECONDS è 0 perché tutti i dati utente confermati tra il cluster database primario e il cluster database secondario sono ancora gli stessi. Al termine dell'istruzione COMMIT, il valore RPO_LAG_IN_MILLISECONDS aumenta.

Monitoraggio dei database globali Aurora basati su PostgreSQL

Per visualizzare lo stato di un database globale Aurora basato su PostgreSQL, occorre utilizzare le funzioni aurora_global_db_status e aurora_global_db_instance_status.

Nota

Solo Aurora PostgreSQL supporta le funzioni aurora_global_db_status e aurora_global_db_instance_status.

Per monitorare un database globale basato su Aurora PostgreSQL

  1. Connettersi all'endpoint cluster primario del database globale utilizzando un'utilità PostgreSQL come psql. Per ulteriori informazioni su come connettersi, consulta Connessione a un database globale Amazon Aurora.

  2. Utilizzare la funzione aurora_global_db_status in un comando psql per elencare i volumi primari e secondari. Mostra i tempi di ritardo dei cluster DB secondari del database 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)

    L'output include una riga per ogni cluster DB del database globale contenente le seguenti colonne:

    • aws_region: la Regione AWS in cui si trova questo cluster di database. Per le tabelle che elencano le Regioni AWS in base al motore, consulta Regioni e zone di disponibilità.

    • highest_lsn_written – Il numero di sequenza di log più alto (LSN) attualmente scritto in questo cluster DB.

      Numero di sequenza di log (LSN) è un numero sequenziale univoco che identifica un record nel log delle transazioni del database. Gli LSN sono ordinati in modo tale che un LSN più grande rappresenti una transazione successiva.

    • durability_lag_in_msec – La differenza di timestamp tra il numero di sequenza di log più alto scritto su un cluster DB secondario (highest_lsn_written) e il highest_lsn_written sul cluster DB primario.

    • rpo_lag_in_msec – Il ritardo dell'obiettivo del punto di ripristino (RPO). Questo ritardo è la differenza di tempo tra il commit delle transazioni utente più recenti memorizzate in un cluster DB secondario e il commit delle transazioni utente più recenti memorizzate nel cluster DB primario.

    • last_lag_calculation_time – Il timestamp in cui sono stati calcolati i valori per durability_lag_in_msec e rpo_lag_in_msec.

    • feedback_epoch – L'epoca utilizzata da un cluster di database secondario quando genera informazioni di standby a caldo.

      Hot Standby – Si verifica quando un cluster DB può connettersi e interrogare mentre il server è in modalità di ripristino o standby. Il feedback hot standby è costituito da informazioni sul cluster DB quando è in standby. Per ulteriori informazioni, consulta Hot Standby nella documentazione di PostgreSQL.

    • feedback_xmin – L'ID minimo della transazione attiva (meno recente) utilizzato da un cluster di database secondario.

  3. Utilizzare la funzione aurora_global_db_instance_status per elencare tutte le istanze database secondarie sia per il cluster DB primario che per i cluster DB secondari.

    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)

    L'output include una riga per ogni istanza DB del database globale contenente le colonne seguenti:

    • server_id – Identificatore del server per l'istanza DB.

    • session_id – Un identificatore univoco per la sessione corrente.

    • aws_region: la Regione AWS in cui si trova questa istanza database. Per le tabelle che elencano le Regioni AWS in base al motore, consulta Regioni e zone di disponibilità.

    • durable_lsn – LSN è stato reso durevole nello storage.

    • highest_lsn_rcvd – L'LSN più alto che l'istanza database ha ricevuto dall'istanza database di scrittura.

    • feedback_epoch – L'epoca utilizzata dall'istanza DB quando genera informazioni di hot standby.

      Standby a caldo è quando un'istanza database può connettersi ed eseguire query mentre il server è in modalità di ripristino o standby. Il feedback hot standby consiste in informazioni sull'istanza DB quando è in hot standby. Per ulteriori informazioni, consulta la documentazione di PostgreSQL su Hot Standby.

    • feedback_xmin – L'ID della transazione attiva minimo (meno recente) utilizzato dall'istanza DB.

    • oldest_read_view_lsn – L’LSN più vecchio utilizzato dall'istanza DB per leggere dallo storage.

    • visibility_lag_in_msec – Quanto questa istanza DB è in ritardo rispetto all'istanza DB di scrittura.

Per vedere come questi valori cambiano nel tempo, considerare il seguente blocco di transazioni in cui un inserimento di tabella richiede un'ora:

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

In alcuni casi, potrebbe esserci una disconnessione di rete tra il cluster DB primario e il cluster DB secondario dopo l'istruzione BEGIN. In tal caso, il valore durability_lag_in_msec del cluster DB secondario inizia ad aumentare. Alla fine dell'istruzione INSERT, il valore durability_lag_in_msec è 1 ora. Tuttavia, il valore rpo_lag_in_msec è 0 perché tutti i dati utente impegnati tra il cluster DB primario e il cluster DB secondario sono ancora gli stessi. Non appena l'istruzione COMMIT viene completata, il valore rpo_lag_in_msec aumenta.