Monitorar um banco de dados global do Amazon Aurora

Ao criar os clusters de bancos de dados Aurora que compõem seu banco de dados Aurora global, você pode escolher muitas opções que permitem monitorar a performance do cluster de banco de dados. As opções incluem o seguinte:

• Amazon RDS Performance Insights – Habilita o esquema de performance no mecanismo de banco de dados do Aurora subjacente Para saber mais sobre Performance Insights e bancos de dados Aurora globais, consulte Monitorando um banco de dados Amazon Aurora global com Performance Insights Amazon RDS.

• Monitoramento aprimorado – Gera métricas para utilização de processos ou thread na CPU. Para saber mais sobre o monitoramento aprimorado, consulte Monitorar métricas do SO com o monitoramento avançado.

• Amazon CloudWatch Logs – Publica tipos de log especificados para CloudWatch Logs. Os logs de erros são publicados por padrão, mas você pode escolher outros logs específicos para o mecanismo de banco de dados do Aurora.

  • Para clusters de bancos de dados Aurora baseados em Aurora MySQL–, você pode exportar o log de auditoria, o log geral e o log de consulta lenta.

  • Para clusters de bancos de dados do Aurora baseados no Aurora PostgreSQL, você pode exportar o log do PostgreSQL.

• Quanto aos bancos de dados globais baseados no Aurora MySQL, você pode consultar tabelas information_schema específicas para conferir o status do banco de dados global do Aurora e as respectivas instâncias. Para saber como, consulte Monitorar bancos de dados globais baseados no Aurora MySQL.

• Quanto a bancos de dados globais baseados no Aurora PostgreSQL, você pode usar funções específicas para conferir o status do banco de dados global do Aurora e as respectivas instâncias. Para saber como, consulte Monitorar banco de dados globais baseados no Aurora PostgreSQL.

A captura de tela a seguir mostra algumas das opções disponíveis na guia Monitoring (Monitoramento) de um cluster de bancos de dados Aurora primário em um banco de dados Aurora global.

Para obter mais informações, consulte Monitorar métricas em um cluster do Amazon Aurora.

Monitorando um banco de dados Amazon Aurora global com Performance Insights Amazon RDS

É possível usar o Performance Insights Amazon RDS e seus bancos de dados do Aurora globais. Você habilita esse recurso individualmente, para cada cluster de bancos de dados Aurora em seu banco de dados do Aurora global. Para isso, escolha Enable Performance Insights (Habilitar Performance Insights) na seção Additional configuration (Configuração adicional) da página Create database (Criar banco de dados). Ou, você pode Modificar seus clusters de banco de dados Aurora para usar esse recurso depois que estiverem em execução. É possível habilitar ou desabilitar o Performance Insights para cada cluster que faz parte do seu banco de dados do Aurora global.

Os relatórios criados pelo Performance Insights aplicam-se a cada cluster no banco de dados global. Ao adicionar uma nova Região da AWS secundária ao Aurora Global Database, que já está usando o Performance Insights, certifique-se de habilitar o Performance Insights no cluster recém-adicionado. Ele não herda a configuração de Performance Insights do banco de dados global existente.

É possível alternar entre Regiões da AWS enquanto visualiza a página do Performance Insights de uma instância de banco de dados anexada a um banco de dados global. No entanto, talvez você não veja as informações sobre a performance imediatamente após alternar entre as Regiões da AWS. Embora as instâncias de banco de dados possam ter nomes idênticos em cada Região da AWS, o URL associado ao Performance Insights é diferente para cada instância de banco de dados. Após alternar entre Regiões da AWS, selecione o nome da instância de banco de dados novamente no painel de navegação de Performance Insights.

Para instâncias de banco de dados associadas a um banco de dados global, os fatores que afetam a performance podem ser diferentes em cada Região da AWS. Por exemplo, as instâncias de banco de dados em cada Região da AWS podem ter uma capacidade diferente.

Para saber mais sobre como usar o Performance Insights, consulte Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora.

Monitorar bancos de dados globais Aurora com fluxos de atividades de banco de dados

Ao usar fluxos de atividade de banco de dados, você pode monitorar e definir alarmes para atividades de auditoria nos cluster de banco de dados em seu banco de dados global. Você inicia um fluxo de atividade de banco de dados em cada cluster de banco de dados separadamente. Cada cluster fornece dados de auditoria ao seu próprio fluxo do Kinesis dentro de sua própria Região da AWS. Para obter mais informações, consulte Monitorar o Amazon Aurora com o recurso Database Activity Streams.

Monitorar bancos de dados globais baseados no Aurora MySQL

Para visualizar o status de um banco de dados global baseado no Aurora MySQL, consulte as tabelas information_schema.aurora_global_db_status e information_schema.aurora_global_db_instance_status.

nota

As tabelas information_schema.aurora_global_db_status e information_schema.aurora_global_db_instance_status só estão disponíveis com bancos de dados globais do Aurora MySQL versão 3.04.0 e posterior.

Como monitorar um banco de dados global baseado no Aurora MySQL

1. Conecte-se ao endpoint do cluster primário do banco de dados global usando um cliente MySQL. Para obter mais informações sobre como se conectar, consulte Conectar-se a um banco de dados do Amazon Aurora global.

2. Consulte a tabela information_schema.aurora_global_db_status em um comando mysql para listar os volumes primário e secundário. Essa consulta retorna os tempos de atraso dos clusters de banco de dados secundários do banco de dados global, como no exemplo a seguir.

   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)

   A saída inclui uma linha para cada cluster de banco de dados global que contém as seguintes colunas:

   • AWS_REGION: a Região da AWS em que esse cluster de banco de dados está. Veja as tabelas que listam Regiões da AWS por mecanismo em Regiões e zonas de disponibilidade.

   • atualmente gravado nesse cluster de banco deHIGHEST_LSN_WRITTEN: o maior número de sequência de log (LSN) atualmente gravado nesse cluster de banco de dados.

     Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior.

   • DURABILITY_LAG_IN_MILLISECONDS: a diferença nos valores de carimbo de data e hora entre o HIGHEST_LSN_WRITTEN em um cluster de banco de dados secundário e o HIGHEST_LSN_WRITTEN no cluster de banco de dados primário. Esse valor é sempre 0 no cluster de banco de dados primário do banco de dados global do Aurora.

   • RPO_LAG_IN_MILLISECONDS: o atraso do objetivo de ponto de recuperação (RPO). O atraso do RPO é o tempo necessário para que a transação COMMIT mais recente do usuário seja armazenada em um cluster de banco de dados secundário após ser armazenada no cluster de banco de dados primário de um banco de dados Aurora global. Esse valor é sempre 0 no cluster de banco de dados primário do banco de dados global do Aurora.

     Em termos simples, essa métrica calcula o objetivo do ponto de recuperação de cada cluster de banco de dados do Aurora MySQL no banco de dados global do Aurora, ou seja, quantos dados poderão ser perdidos se houver uma interrupção. Tal como o atraso, o RPO é medido em tempo.

   • LAST_LAG_CALCULATION_TIMESTAMP: o carimbo de data e hora que especifica quando os valores foram calculados pela última vez para DURABILITY_LAG_IN_MILLISECONDS e RPO_LAG_IN_MILLISECONDS. Um valor de tempo como 1970-01-01 00:00:00+00 indica que este é o cluster de banco de dados primário.

   • OLDEST_READ_VIEW_TRX_ID: o ID da transação mais antiga que a instância de banco de dados do gravador pode limpar.

3. Consulte a tabela information_schema.aurora_global_db_instance_status para listar todas as instâncias de banco de dados secundárias tanto para o cluster de banco de dados primário como para os clusters de banco de dados secundários.

   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)

   A saída inclui uma linha para cada instância de banco de dados global que contém as seguintes colunas:

   • SERVER_ID: o identificador do servidor para a instância de banco de dados.

   • SESSION_ID: um identificador exclusivo para a sessão atual. O valor de MASTER_SESSION_ID identifica a instância de banco de dados do leitor (primário).

   • AWS_REGION: a Região da AWS em que essa instância de banco de dados está. Veja as tabelas que listam Regiões da AWS por mecanismo em Regiões e zonas de disponibilidade.

   • DURABLE_LSN: o LSN tornou-se durável no armazenamento.

   • HIGHEST_LSN_RECEIVED: o LSN mais alto recebido pela instância de banco de dados da instância de banco de dados do gravador.

   • OLDEST_READ_VIEW_TRX_ID: o ID da transação mais antiga que a instância de banco de dados do gravador pode limpar.

   • OLDEST_READ_VIEW_LSN: o LSN mais antigo usado pela instância de banco de dados para fazer a leitura no armazenamento.

   • VISIBILITY_LAG_IN_MSEC: para leitores no cluster de banco de dados primário, até que ponto essa instância de banco de dados está atrasada em relação à instância de banco de dados de gravador em milissegundos. Para leitores em um cluster de banco de dados secundário, até que ponto essa instância de banco de dados está atrasada em relação ao volume secundário em milissegundos.

Para ver como esses valores mudam ao longo do tempo, considere o bloco de transação a seguir, em que uma inserção de tabela leva uma hora.

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

Em alguns casos, pode haver uma desconexão de rede entre o cluster de banco de dados primário e o cluster de banco de dados secundário após a declaração BEGIN. Em caso afirmativo, o valor DURABILITY_LAG_EM_MILISSEGUNDOS do cluster de banco de dados secundário começa a aumentar. No final da declaração INSERT, o valor DURABILITY_LAG_EM_MILISSEGUNDOS é de 1 hora. No entanto, o valor RPO_LAG_IN_MILLISECONDS é 0 porque todos os dados do usuário confirmados entre o cluster de banco de dados primário e o cluster de banco de dados secundário ainda são os mesmos. Assim que a declaração COMMIT é concluída, o valor RPO_LAG_IN_MILISSEGUNDOS aumenta.

Monitorar banco de dados globais baseados no Aurora PostgreSQL

Para visualizar o status de um banco de dados global baseado no Aurora PostgreSQL, use as funções aurora_global_db_status e aurora_global_db_instance_status.

nota

Somente o Aurora PostgreSQL oferece suporte às funções aurora_global_db_status e aurora_global_db_instance_status.

Para monitorar um banco de dados global baseado em Aurora PostgreSQL

1. Conecte-se ao endpoint de cluster primário do banco de dados global usando um utilitário do PostgreSQL, como psql. Para obter mais informações sobre como se conectar, consulte Conectar-se a um banco de dados do Amazon Aurora global.

2. Use a função aurora_global_db_status em um comando psql para listar os volumes primário e secundário. Isso mostra os tempos de atraso dos clusters de banco de dados secundários do banco de dados global.

   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)

   A saída inclui uma linha para cada cluster de banco de dados global que contém as seguintes colunas:

   • aws_region: a Região da AWS em que esse cluster de banco de dados está. Veja as tabelas que listam Regiões da AWS por mecanismo em Regiões e zonas de disponibilidade.

   • highest_lsn_written: o maior número de sequência de log (LSN) atualmente gravado nesse cluster de banco de dados.

     Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior.

   • durability_lag_in_msec: a diferença de time stamp entre o número de sequência de log mais alto gravado em um cluster de banco de dados secundário (highest_lsn_written) e o highest_lsn_written no cluster de banco de dados primário.

   • rpo_lag_in_msec: o atraso do Objetivo de ponto de recuperação gerenciado (RPO). Esse atraso é a diferença de tempo entre a confirmação da transação do usuário mais recente armazenada em um cluster de banco de dados secundário e a confirmação da transação do usuário mais recente armazenada no cluster do banco de dados primário.

   • last_lag_calculation_time: o time stamp em que os valores foram calculados pela última vez para durability_lag_in_msec e rpo_lag_in_msec.

   • feedback_epoch: epoch que um cluster de banco de dados secundário usa quando gera informações de standby a quente.

     O standby a quente acontece quando um cluster de banco de dados pode se conectar e consultar enquanto o servidor está no modo de recuperação ou de espera. O feedback de standby a quente são informações sobre o cluster de banco de dados quando ele está em standby a quente. Para obter mais informações, consulte Hot standby na documentação do PostgreSQL.

   • feedback_xmin: o ID mínimo (mais antigo) de transação ativo usado por um cluster de banco de dados secundário.

3. Use a função aurora_global_db_instance_status para listar todas as instâncias de banco de dados secundárias tanto para o cluster de banco de dados primário como para os clusters de banco de dados secundários.

   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)

   A saída inclui uma linha para cada instância de banco de dados global que contém as seguintes colunas:

   • server_id: o identificador do servidor para a instância de banco de dados.

   • session_id: um identificador exclusivo para a sessão atual.

   • aws_region: a Região da AWS em que essa instância de banco de dados está. Veja as tabelas que listam Regiões da AWS por mecanismo em Regiões e zonas de disponibilidade.

   • durable_lsn – o LSN tornou-se durável no armazenamento.

   • highest_lsn_rcvd: o LSN mais alto recebido pela instância de banco de dados da instância de banco de dados do gravador.

   • feedback_epoch: a época que a instância de banco de dados usa quando gera informações de standby a quente.

     O standby a quente acontece quando uma instância de banco de dados pode se conectar e consultar enquanto o servidor está no modo de recuperação ou espera. O feedback de standby a quente são informações sobre a instância de banco de dados quando ela está em standby a quente. Para obter mais informações, consulte a documentação do PostgreSQL em Hot standby.

   • feedback_xmin: o ID mínimo (mais antigo) de transação ativo usado pela instância de banco de dados.

   • oldest_read_view_lsn: o LSN mais antigo usado pela instância de banco de dados para fazer a leitura no armazenamento.

   • visibility_lag_in_msec: até que ponto essa instância de banco de dados está atrasada em relação à instância de banco de dados do gravador.

Para ver como esses valores mudam ao longo do tempo, considere o bloco de transação a seguir, em que uma inserção de tabela leva uma hora.

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

Em alguns casos, pode haver uma desconexão de rede entre o cluster de banco de dados primário e o cluster de banco de dados secundário após a instrução BEGIN. Nesse caso, o valor durability_lag_in_msec do cluster de banco de dados secundário começa a aumentar. No final da instrução INSERT, o durability_lag_in_msec valor é 1 hora. No entanto, o valor rpo_lag_in_msec é 0 porque todos os dados do usuário confirmados entre o cluster de banco de dados primário e o cluster de banco de dados secundário ainda são os mesmos. Assim que a instrução COMMIT for concluída, o valor rpo_lag_in_msec aumentará.