# Solucionar problemas de desempenho do banco de dados do Amazon Aurora MySQL
Esse tópico se concentra em alguns problemas comuns de desempenho do banco de dados do Aurora MySQL e em como solucionar ou coletar informações para corrigir esses problemas rapidamente. Dividimos o desempenho do banco de dados em duas categorias:
+ Desempenho do servidor: todo o servidor do banco de dados é executado mais lentamente.
+ Desempenho da consulta: uma ou mais consultas demoram mais para serem executadas.
## Opções de monitoramento da AWS
Recomendamos que você use as opções de monitoramento da AWS a seguir para ajudar na solução de problemas:
+ Amazon CloudWatch: o Amazon CloudWatch monitora os recursos da AWS e as aplicações que você executa na AWS em tempo real. Você pode usar o CloudWatch para coletar e monitorar métricas, que são as variáveis mensuráveis que ajudam você a avaliar seus recursos e aplicativos. Consulte mais informações em [O que é o Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
É possível visualizar todas as métricas e informações de processo do sistema das instâncias de banco de dados no Console de gerenciamento da AWS. É possível configurar seu cluster de banco de dados Aurora MySQL para publicar dados de logs gerais, lentos, de auditoria e de erros em um grupo de logs no Amazon CloudWatch Logs. Isso permite que você visualize tendências, mantenha logs se um host for afetado e crie uma linha de base para o desempenho “normal” a fim de identificar facilmente anomalias ou alterações. Para ter mais informações, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md).
+ Monitoramento avançado: para habilitar métricas adicionais do Amazon CloudWatch para um banco de dados do Aurora MySQL, ative o monitoramento avançado. Ao criar ou modificar um cluster de banco de dados do Aurora, selecione **Habilitar monitoramento avançado**. Isso permite que o Aurora publique métricas de desempenho no CloudWatch. Algumas das principais métricas disponíveis incluem uso de CPU, conexões de banco de dados, uso de armazenamento e latência de consultas. Elas podem ajudar a identificar gargalos de desempenho.
A quantidade de informações transferidas para uma instância de banco de dados é diretamente proporcional à granularidade definida para o monitoramento avançado. Um menor intervalo de monitoramento resulta em relatórios mais frequentes das métricas do sistema operacional e aumenta seu custo de monitoramento. Para gerenciar custos, defina diferentes detalhamentos para diferentes instâncias nas Contas da AWS. A granularidade padrão na criação de uma instância é de 60 segundos. Para ter mais informações, consulte [Custo do monitoramento avançado](USER_Monitoring.OS.md#USER_Monitoring.OS.cost).
+ Performance Insights: é possível visualizar todas as métricas de chamadas do banco de dados. Isso inclui bloqueios de banco de dados, esperas e o número de linhas processadas, todos os quais você pode usar para solucionar problemas. Ao criar ou modificar um cluster de banco de dados do Aurora, selecione **Ativar o Performance Insights**. Por padrão, o Performance Insights tem um período de retenção de dados de sete dias, mas pode ser personalizado para analisar tendências de desempenho de prazo maior. Para retenção de mais de sete dias, você precisa fazer upgrade para o nível pago. Consulte mais informações em [Definição de preço do Performance Insights](https://aws.amazon.com/rds/performance-insights/pricing/). É possível definir o período de retenção de dados para cada instância de banco de dados do Aurora separadamente. Para ter mais informações, consulte [Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora](USER_PerfInsights.md).
## Motivos mais comuns para problemas de performance do banco de dados MySQL
É possível usar as etapas a seguir para solucionar problemas de desempenho no banco de dados do Aurora MySQL. Listamos essas etapas na ordem lógica da investigação, mas elas não são obrigatoriamente lineares. Uma descoberta pode ignorar certas etapas, o que permite uma série de caminhos investigativos.
1. [Workload](aurora-mysql-troubleshooting-workload.md): entenda a workload do banco de dados.
1. [Registro em log](aurora-mysql-troubleshooting-logging.md): revise todos os logs do banco de dados.
1. [Conexões a bancos de dados](mysql-troubleshooting-dbconn.md): garanta que as conexões entre as aplicações e o banco de dados sejam confiáveis.
1. [Performance de consultas](aurora-mysql-troubleshooting-query.md): examine os planos de execução de consultas para ver se eles mudaram. Alterações no código podem fazer com que os planos mudem.
# Solucionar problemas em workloads para bancos de dados do Aurora MySQL
A workload do banco de dados pode ser vista como leituras e gravações. Com uma compreensão da workload de banco de dados “normal”, é possível ajustar as consultas e o servidor do banco de dados para atender à demanda à medida que ela muda. Há vários motivos pelos quais o desempenho pode mudar, então a primeira etapa é entender o que mudou.
+ Houve um upgrade da versão principal ou secundária?
Um upgrade da versão principal inclui alterações no código do mecanismo, principalmente no otimizador, que podem alterar o plano de execução da consulta. Ao fazer upgrade das versões do banco de dados, especialmente das principais, é muito importante que você analise a workload do banco de dados e ajuste adequadamente. O ajuste pode envolver a otimização e a reescrita de consultas ou a adição e atualização de configurações de parâmetros, dependendo dos resultados dos testes. Entender o que está causando o impacto permitirá que você comece a se concentrar nessa área específica.
Consulte mais informações em [What is new in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) e [Server and status variables and options added, deprecated, or removed in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html) na documentação do MySQL, e [Comparar o Aurora MySQL versão 2 e o Aurora MySQL versão 3](AuroraMySQL.Compare-v2-v3.md).
+ Houve um aumento no processamento de dados (contagem de linhas)?
+ Há mais consultas sendo executadas simultaneamente?
+ Há alterações no esquema ou no banco de dados?
+ Houve defeitos ou correções no código?
**Contents**
+ [Métricas de host da instância](#ams-workload-instance)
+ [Uso da CPU](#ams-workload-cpu)
+ [Uso de memória](#ams-workload-instance-memory)
+ [Throughput na rede](#ams-workload-network)
+ [Métricas de banco de dados](#ams-workload-db)
+ [Solução de problemas de uso de memória para bancos de dados Aurora MySQL](ams-workload-memory.md)
+ [Exemplo 1: Alto uso contínuo de memória](ams-workload-memory.md#ams-workload-memory.example1)
+ [Exemplo 2: Picos transitórios de memória](ams-workload-memory.md#ams-workload-memory.example2)
+ [Exemplo 3: A memória liberável cai continuamente e não é recuperada](ams-workload-memory.md#ams-workload-memory.example3)
+ [Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL](AuroraMySQLOOM.md)
## Métricas de host da instância
Monitore as métricas do host da instância, como CPU, memória e atividade de rede, para ajudar a entender se houve uma alteração na workload. Há dois conceitos principais para entender as mudanças na workload:
+ Utilização: o uso de um dispositivo, como CPU ou disco. Pode ser com base no tempo ou na capacidade.
+ Com base no tempo: a quantidade de tempo em que um recurso está ocupado durante determinado período de observação.
+ Com base na capacidade: a quantidade de throughput que um sistema ou componente pode fornecer, como uma porcentagem de sua capacidade.
+ Saturação: o grau em que mais trabalho é exigido de um recurso do que ele pode processar. Quando o uso com base na capacidade atinge 100%, o trabalho extra não pode ser processado e deve ser colocado na fila.
### Uso da CPU
É possível usar as seguintes ferramentas para identificar o uso e a saturação da CPU:
+ O CloudWatch fornece a métrica `CPUUtilization`. Se isso atingir 100%, a instância estará saturada. No entanto, as métricas do CloudWatch são calculadas em média em mais de um minuto e carecem de granularidade.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
+ O monitoramento aprimorado fornece métricas retornadas pelo comando `top` do sistema operacional. Ele mostra as médias de carga e os seguintes estados de CPU, com granularidade de um segundo:
+ `Idle (%)` = tempo ocioso
+ `IRQ (%)` = interrupções de software
+ `Nice (%)` = bom momento para processos com uma [boa](https://en.wikipedia.org/wiki/Nice_(Unix)) prioridade.
+ `Steal (%)` = tempo gasto atendendo outros locatários (relacionado à virtualização)
+ `System (%)` = hora do sistema
+ `User (%)` = hora do usuário
+ `Wait (%)` = espera de E/S
Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte [Métricas do SO para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
### Uso de memória
Se o sistema estiver sob pressão de memória e o consumo de recursos estiver atingindo a saturação, você deverá observar um alto grau de erros de digitalização, paginação, troca e falta de memória.
É possível usar as seguintes ferramentas para identificar o uso e a saturação da memória:
O CloudWatch fornece a métrica `FreeableMemory` que mostra quanta memória pode ser recuperada limpando alguns dos caches do sistema operacional e a memória livre atual.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
O monitoramento avançado fornece as seguintes métricas que podem ajudar a identificar problemas de uso de memória:
+ `Buffers (KB)`: a quantidade de memória usada para o buffer de solicitações de E/S antes de gravar no dispositivo de armazenamento, em kilobytes.
+ `Cached (KB)`: a quantidade de memória utilizada para o armazenamento em cache da E/S baseada no sistema de arquivos.
+ `Free (KB)`: a quantidade de memória não atribuída, em kilobytes.
+ `Swap`: em cache, livre e total.
Por exemplo, se você perceber que a instância de banco de dados usa memória `Swap`, a quantidade total de memória para sua workload será maior do que a instância tem disponível atualmente. Recomendamos aumentar o tamanho da instância de banco de dados ou ajustar a workload para usar menos memória.
Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte [Métricas do SO para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
Para ter informações mais detalhadas sobre como usar o Esquema de Performance e o esquema `sys` para determinar quais conexões e componentes estão usando memória, consulte [Solução de problemas de uso de memória para bancos de dados Aurora MySQL](ams-workload-memory.md).
### Throughput na rede
O CloudWatch fornece as seguintes métricas para throughput total da rede, todas com média de um minuto:
+ `NetworkReceiveThroughput`: a quantidade de throughput de rede recebida dos clientes por cada instância no cluster de bancos de dados do Aurora.
+ `NetworkTransmitThroughput`: a quantidade de throughput de rede enviada aos clientes por cada instância no cluster de bancos de dados do Aurora.
+ `NetworkThroughput`: a quantidade de throughput de rede recebida e transmitida aos clientes por cada instância no cluster de bancos de dados do Aurora.
+ `StorageNetworkReceiveThroughput`: a quantidade de throughput de rede recebida do subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados.
+ `StorageNetworkTransmitThroughput`: a quantidade de throughput de rede enviada ao subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados do Aurora.
+ `StorageNetworkThroughput`: a quantidade de throughput de rede recebida e enviada ao subsistema de armazenamento do Aurora por cada instância no cluster de banco de dados do Aurora.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
O monitoramento avançado fornece os grafos `network` recebidos (**RX**) e transmitidos (**TX**), com granularidade de até um segundo.
Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte [Métricas do SO para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
## Métricas de banco de dados
Examine as seguintes métricas do CloudWatch para alterações na workload:
+ `BlockedTransactions`: o número médio de transações no banco de dados que são bloqueadas por segundo.
+ `BufferCacheHitRatio`: a porcentagem de solicitações atendidas pelo cache de buffer.
+ `CommitThroughput`: o número médio de operações de confirmação por segundo.
+ `DatabaseConnections`: o número de conexões de rede cliente com a instância de banco de dados.
+ `Deadlocks`: o número médio de deadlocks no banco de dados por segundo.
+ `DMLThroughput`: o número médio de inserções, atualizações e exclusões por segundo.
+ `ResultSetCacheHitRatio`: a porcentagem de solicitações atendidas pelo cache de consulta.
+ `RollbackSegmentHistoryListLength`: os logs de ações desfeitas que registram transações confirmadas com registros marcados para exclusão.
+ `RowLockTime`: o tempo total gasto adquirindo bloqueios de linha para tabelas do InnoDB.
+ `SelectThroughput`: o número médio de consultas de seleção por segundo.
Para obter mais informações sobre métricas do CloudWatch, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
Considere as seguintes perguntas ao examinar a workload:
1. Houve mudanças recentes na classe da instância de banco de dados, por exemplo, redução do tamanho da instância de 8xlarge para 4xlarge ou alteração de db.r5 para db.r6?
1. É possível criar um clone e reproduzir o problema ou isso acontece apenas nessa instância?
1. Há esgotamento dos recursos do servidor, alto esgotamento da CPU ou da memória? Se sim, isso pode significar a necessidade de hardware adicional.
1. Uma ou mais consultas estão demorando mais?
1. As alterações são causadas por um upgrade, especialmente de uma versão principal? Se sim, compare as métricas de antes e depois do upgrade.
1. Há mudanças no número de instâncias de banco de dados do leitor?
1. Você habilitou os logs gerais, de auditoria ou binários? Para ter mais informações, consulte [Registro em log de bancos de dados do Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. Você habilitou, desabilitou ou alterou o uso da replicação de logs binários (binlogs)?
1. Há alguma transação de longa duração com um grande número de bloqueios de linha? Examine o tamanho da lista de histórico do InnoDB (HLL) para obter indicações de transações de longa duração.
Consulte mais informações em [O tamanho da lista de histórico do InnoDB aumentou significativamente](proactive-insights.history-list.md) e na publicação do blog [Why is my SELECT query running slowly on my Amazon Aurora MySQL DB cluster?](https://repost.aws/knowledge-center/aurora-mysql-slow-select-query).
1. Se um grande HLL for causado por uma transação de gravação, isso significa que os logs `UNDO` estão se acumulando (não estão sendo limpos regularmente). Em uma grande transação de gravação, esse acúmulo pode crescer rapidamente. No MySQL, `UNDO` é armazenado no [espaço de tabela SYSTEM](https://dev.mysql.com/doc/refman/5.7/en/innodb-system-tablespace.html). O espaço de tabela `SYSTEM` não pode ser reduzido. O log `UNDO` pode fazer com que o espaço de tabela `SYSTEM` cresça para vários GB, ou até mesmo TB. Após a limpeza, libere o espaço alocado fazendo backup lógico (despejo) dos dados e, depois, importe o despejo para uma nova instância de banco de dados.
1. Se um HLL grande for causado por uma transação de leitura (consulta de longa duração), isso poderá indicar que a consulta está usando uma grande quantidade de espaço temporário. Libere o espaço temporário ao reinicializar. Examine as métricas de banco de dados do Performance Insights para verificar quaisquer alterações na seção `Temp`, como `created_tmp_tables`. Para ter mais informações, consulte [Monitorar a carga de banco de dados com o Performance Insights no Amazon Aurora](USER_PerfInsights.md).
1. É possível dividir transações de longa duração em transações menores que modificam menos linhas?
1. Há alguma alteração nas transações bloqueadas ou aumento nos deadlocks? Examine as métricas de banco de dados do Performance Insights para verificar quaisquer alterações nas variáveis de status na seção `Locks`, como `innodb_row_lock_time`, ` innodb_row_lock_waits` e ` innodb_dead_locks`. Use intervalos de um minuto ou de cinco minutos.
1. Há um aumento nos eventos de espera? Examine os eventos de espera e os tipos de espera do Performance Insights usando intervalos de um minuto ou de cinco minutos. Analise os principais eventos de espera e veja se eles estão correlacionados às mudanças na workload ou à contenção do banco de dados. Por exemplo, `buf_pool mutex` indica a contenção do grupo de buffer. Para ter mais informações, consulte [Ajustar o Aurora MySQL com eventos de espera](AuroraMySQL.Managing.Tuning.wait-events.md).
# Solução de problemas de uso de memória para bancos de dados Aurora MySQL
Embora o CloudWatch, o Monitoramento Avançado e o Insights de Performance ofereçam uma boa visão geral do uso da memória em nível de sistema operacional, como a quantidade de memória que o processo do banco de dados está usando, eles não permitem definir quais conexões ou componentes no mecanismo podem estar causando esse uso de memória.
Para solucionar esse problema, é possível usar o Esquema de Performance e o esquema `sys`. No Aurora MySQL versão 3, a instrumentação de memória está habilitada por padrão quando o Esquema de Performance está habilitado. No Aurora MySQL versão 2, somente a instrumentação de memória para uso de memória do Esquema de Performance está habilitada por padrão. Para ter informações sobre tabelas disponíveis no Esquema de Performance para monitorar o uso da memória e habilitar a instrumentação de memória do Esquema de Performance, consulte [Memory summary tables](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) na documentação do MySQL. Para ter mais informações sobre o uso do Esquema de Performance com o Insights de Performance, consulte [Visão geral do Performance Schema para o Insights de Performance no Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
Embora informações detalhadas estejam disponíveis no Esquema de Performance para monitorar o uso atual da memória, o [esquema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) MySQL tem visualizações sobre as tabelas do Esquema de Performance que você pode usar para identificar rapidamente onde a memória está sendo usada.
No esquema `sys`, as visualizações a seguir estão disponíveis para monitorar o uso da memória por conexão, componente e consulta.
| Visualizar | Descrição |
| --- | --- |
| [memory\$1by\$1host\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-host-by-current-bytes.html) | Fornece informações sobre o uso da memória do mecanismo por host. Pode ser útil para identificar quais servidores de aplicações ou hosts de clientes estão consumindo memória. |
| [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html) | Fornece informações sobre o uso da memória do mecanismo por ID de thread. O ID de thread no MySQL pode ser uma conexão de cliente ou um thread em segundo plano. É possível associar IDs de thread a IDs de conexão MySQL usando a visualização [sys.processlist](https://dev.mysql.com/doc/refman/8.0/en/sys-processlist.html) ou a tabela [performance\$1schema.threads](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-threads-table.html). |
| [memory\$1by\$1user\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-user-by-current-bytes.html) | Fornece informações sobre o uso da memória do mecanismo por usuário. Pode ser útil para identificar quais contas de usuário ou clientes estão consumindo memória. |
| [memory\$1global\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-by-current-bytes.html) | Fornece informações sobre o uso da memória do mecanismo por componente do mecanismo. Pode ser útil para identificar o uso de memória globalmente pelos buffers ou componentes do mecanismo. Por exemplo, é possível que você veja o evento `memory/innodb/buf_buf_pool` para o grupo de buffer InnoDB ou o evento `memory/sql/Prepared_statement::main_mem_root` para declarações preparadas. |
| [memory\$1global\$1total](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-global-total.html) | Fornece uma visão geral do uso total de memória monitorado no mecanismo de banco de dados. |
No Aurora MySQL versão 3.05 e posterior, também é possível monitorar o uso máximo de memória por resumo de declarações nas [tabelas de resumo de declarações do Esquema de Performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html). As tabelas de resumo de declarações contêm resumos de declarações normalizados e estatísticas agregadas sobre a execução. A coluna `MAX_TOTAL_MEMORY` pode ajudar a identificar a memória máxima usada pelo resumo da consulta desde a última redefinição das estatísticas ou desde que a instância do banco de dados foi reiniciada. Pode ser útil para identificar consultas específicas que podem estar consumindo muita memória.
**nota**
O Esquema de Performance e o esquema `sys` mostram o uso atual da memória no servidor e os limites máximos da memória consumida por conexão e componente do mecanismo. Como o Esquema de Performance é mantido na memória, as informações são redefinidas quando a instância de banco de dados é reiniciada. Para manter um histórico ao longo do tempo, recomendamos configurar a recuperação e o armazenamento desses dados fora do Esquema de Performance.
**Topics**
+ [Exemplo 1: Alto uso contínuo de memória](#ams-workload-memory.example1)
+ [Exemplo 2: Picos transitórios de memória](#ams-workload-memory.example2)
+ [Exemplo 3: A memória liberável cai continuamente e não é recuperada](#ams-workload-memory.example3)
## Exemplo 1: Alto uso contínuo de memória
Examinando globalmente o `FreeableMemory` no CloudWatch, podemos ver que o uso de memória aumentou muito em 26/3/2024, 2:59, Tempo Universal Coordenado.
![\[Grafo FreeableMemory mostrando alto uso de memória.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ams-freeable-memory.png)
Ele não exibe o panorama geral. Para determinar qual componente está usando mais memória, é possível fazer login no banco de dados e verificar `sys.memory_global_by_current_bytes`. Essa tabela contém uma lista de eventos de memória monitorados pelo MySQL, além de informações sobre alocação de memória por evento. Cada evento de monitoramento de memória começa com `memory/%`, seguido de outras informações sobre o componente/recurso do mecanismo ao qual o evento está associado.
Por exemplo, `memory/performance_schema/%` corresponde a eventos de memória relacionados ao Esquema de Performance, `memory/innodb/%` corresponde ao InnoDB etc. Para ter informações sobre as convenções de nomenclatura de eventos, consulte [Performance Schema instrument naming conventions](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html) na documentação do MySQL.
Na consulta a seguir, podemos encontrar o provável culpado com base em `current_alloc`, mas também podemos ver muitos eventos `memory/performance_schema/%`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/performance_schema/prepared_statements_instances | 252 | 488.25 MiB | 1.94 MiB | 252 | 488.25 MiB | 1.94 MiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 1028 | 52.27 MiB | 52.06 KiB | 1028 | 52.27 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 4 | 47.25 MiB | 11.81 MiB | 4 | 47.25 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/performance_schema/memory_summary_by_thread_by_event_name | 4 | 31.64 MiB | 7.91 MiB | 4 | 31.64 MiB | 7.91 MiB |
| memory/innodb/memory | 15227 | 27.44 MiB | 1.85 KiB | 20619 | 33.33 MiB | 1.66 KiB |
| memory/sql/String::value | 74411 | 21.85 MiB | 307 bytes | 76867 | 25.54 MiB | 348 bytes |
| memory/sql/TABLE | 8381 | 21.03 MiB | 2.57 KiB | 8381 | 21.03 MiB | 2.57 KiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.02 sec)
```
Mencionamos anteriormente que o Esquema de Performance é armazenado na memória, o que significa que ele também é monitorado na instrumentação da memória `performance_schema`.
**nota**
Se você achar que o Esquema de Performance está usando muita memória e quiser limitar o uso, poderá ajustar os parâmetros do banco de dados com base nos requisitos. Para ter mais informações, consulte [The Performance Schema memory-allocation model](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-memory-model.html) na documentação do MySQL.
Para facilitar a leitura, é possível executar novamente a mesma consulta, mas excluir os eventos do Esquema de Performance. A saída mostra o seguinte:
+ O principal consumidor de memória é `memory/sql/Prepared_statement::main_mem_root`.
+ A coluna `current_alloc` informa que o MySQL tem 4,91 GiB atualmente alocados para esse evento.
+ A `high_alloc column` informa que 4,91 GiB é o ponto máximo de `current_alloc` desde a última vez que as estatísticas foram redefinidas ou desde a reinicialização do servidor. Isso significa que `memory/sql/Prepared_statement::main_mem_root` está no valor mais alto.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name NOT LIKE 'memory/performance_schema/%' LIMIT 10;
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 512817 | 4.91 GiB | 10.04 KiB | 512823 | 4.91 GiB | 10.04 KiB |
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/memory | 17096 | 31.68 MiB | 1.90 KiB | 22498 | 37.60 MiB | 1.71 KiB |
| memory/sql/String::value | 122277 | 27.94 MiB | 239 bytes | 124699 | 29.47 MiB | 247 bytes |
| memory/sql/TABLE | 9927 | 24.67 MiB | 2.55 KiB | 9929 | 24.68 MiB | 2.55 KiB |
| memory/innodb/lock0lock | 8888 | 19.71 MiB | 2.27 KiB | 8888 | 19.71 MiB | 2.27 KiB |
| memory/sql/Prepared_statement::infrastructure | 257623 | 16.24 MiB | 66 bytes | 257631 | 16.24 MiB | 66 bytes |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/innodb/sync0arr | 3 | 7.03 MiB | 2.34 MiB | 3 | 7.03 MiB | 2.34 MiB |
| memory/sql/THD::main_mem_root | 815 | 6.56 MiB | 8.24 KiB | 849 | 7.19 MiB | 8.67 KiB |
+-----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.06 sec)
```
Pelo nome do evento, podemos dizer que essa memória está sendo usada para declarações preparadas. Se você quiser ver quais conexões estão usando essa memória, poderá conferir [memory\$1by\$1thread\$1by\$1current\$1bytes](https://dev.mysql.com/doc/refman/8.0/en/sys-memory-by-thread-by-current-bytes.html).
No exemplo a seguir, cada conexão tem aproximadamente 7 MiB alocados, com limite máximo de 6,29 MiB (`current_max_alloc`). Isso faz sentido, porque o exemplo está usando `sysbench` com 80 tabelas e 800 conexões com declarações preparadas. Se quiser reduzir o uso de memória nessa situação, poderá otimizar o uso de declarações preparadas pela aplicação para diminuir o consumo de memória.
```
mysql> SELECT * FROM sys.memory_by_thread_by_current_bytes;
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| 46 | rdsadmin@localhost | 405 | 8.47 MiB | 21.42 KiB | 8.00 MiB | 155.86 MiB |
| 61 | reinvent@10.0.4.4 | 1749 | 6.72 MiB | 3.93 KiB | 6.29 MiB | 14.24 MiB |
| 101 | reinvent@10.0.4.4 | 1845 | 6.71 MiB | 3.72 KiB | 6.29 MiB | 14.50 MiB |
| 55 | reinvent@10.0.4.4 | 1674 | 6.68 MiB | 4.09 KiB | 6.29 MiB | 14.13 MiB |
| 57 | reinvent@10.0.4.4 | 1416 | 6.66 MiB | 4.82 KiB | 6.29 MiB | 13.52 MiB |
| 112 | reinvent@10.0.4.4 | 1759 | 6.66 MiB | 3.88 KiB | 6.29 MiB | 14.17 MiB |
| 66 | reinvent@10.0.4.4 | 1428 | 6.64 MiB | 4.76 KiB | 6.29 MiB | 13.47 MiB |
| 75 | reinvent@10.0.4.4 | 1389 | 6.62 MiB | 4.88 KiB | 6.29 MiB | 13.40 MiB |
| 116 | reinvent@10.0.4.4 | 1333 | 6.61 MiB | 5.08 KiB | 6.29 MiB | 13.21 MiB |
| 90 | reinvent@10.0.4.4 | 1448 | 6.59 MiB | 4.66 KiB | 6.29 MiB | 13.58 MiB |
| 98 | reinvent@10.0.4.4 | 1440 | 6.57 MiB | 4.67 KiB | 6.29 MiB | 13.52 MiB |
| 94 | reinvent@10.0.4.4 | 1433 | 6.57 MiB | 4.69 KiB | 6.29 MiB | 13.49 MiB |
| 62 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.48 MiB |
| 87 | reinvent@10.0.4.4 | 1323 | 6.55 MiB | 5.07 KiB | 6.29 MiB | 13.25 MiB |
| 99 | reinvent@10.0.4.4 | 1346 | 6.54 MiB | 4.98 KiB | 6.29 MiB | 13.24 MiB |
| 105 | reinvent@10.0.4.4 | 1347 | 6.54 MiB | 4.97 KiB | 6.29 MiB | 13.34 MiB |
| 73 | reinvent@10.0.4.4 | 1335 | 6.54 MiB | 5.02 KiB | 6.29 MiB | 13.23 MiB |
| 54 | reinvent@10.0.4.4 | 1510 | 6.53 MiB | 4.43 KiB | 6.29 MiB | 13.49 MiB |
. .
. .
. .
| 812 | reinvent@10.0.4.4 | 1259 | 6.38 MiB | 5.19 KiB | 6.29 MiB | 13.05 MiB |
| 214 | reinvent@10.0.4.4 | 1279 | 6.38 MiB | 5.10 KiB | 6.29 MiB | 12.90 MiB |
| 325 | reinvent@10.0.4.4 | 1254 | 6.38 MiB | 5.21 KiB | 6.29 MiB | 12.99 MiB |
| 705 | reinvent@10.0.4.4 | 1273 | 6.37 MiB | 5.13 KiB | 6.29 MiB | 13.03 MiB |
| 530 | reinvent@10.0.4.4 | 1268 | 6.37 MiB | 5.15 KiB | 6.29 MiB | 12.92 MiB |
| 307 | reinvent@10.0.4.4 | 1263 | 6.37 MiB | 5.17 KiB | 6.29 MiB | 12.87 MiB |
| 738 | reinvent@10.0.4.4 | 1260 | 6.37 MiB | 5.18 KiB | 6.29 MiB | 13.00 MiB |
| 819 | reinvent@10.0.4.4 | 1252 | 6.37 MiB | 5.21 KiB | 6.29 MiB | 13.01 MiB |
| 31 | innodb/srv_purge_thread | 17810 | 3.14 MiB | 184 bytes | 2.40 MiB | 205.69 MiB |
| 38 | rdsadmin@localhost | 599 | 1.76 MiB | 3.01 KiB | 1.00 MiB | 25.58 MiB |
| 1 | sql/main | 3756 | 1.32 MiB | 367 bytes | 355.78 KiB | 6.19 MiB |
| 854 | rdsadmin@localhost | 46 | 1.08 MiB | 23.98 KiB | 1.00 MiB | 5.10 MiB |
| 30 | innodb/clone_gtid_thread | 1596 | 573.14 KiB | 367 bytes | 254.91 KiB | 970.69 KiB |
| 40 | rdsadmin@localhost | 235 | 245.19 KiB | 1.04 KiB | 128.88 KiB | 808.64 KiB |
| 853 | rdsadmin@localhost | 96 | 94.63 KiB | 1009 bytes | 29.73 KiB | 422.45 KiB |
| 36 | rdsadmin@localhost | 33 | 36.29 KiB | 1.10 KiB | 16.08 KiB | 74.15 MiB |
| 33 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB |
| 35 | sql/compress_gtid_table | 8 | 14.20 KiB | 1.77 KiB | 8.05 KiB | 18.62 KiB |
| 25 | innodb/fts_optimize_thread | 12 | 1.86 KiB | 158 bytes | 648 bytes | 1.98 KiB |
| 23 | innodb/srv_master_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 24.40 KiB |
| 24 | innodb/dict_stats_thread | 11 | 1.23 KiB | 114 bytes | 361 bytes | 1.35 KiB |
| 5 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 6 | innodb/io_read_thread | 1 | 144 bytes | 144 bytes | 144 bytes | 144 bytes |
| 2 | sql/aws_oscar_log_level_monitor | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 4 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 7 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 8 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 9 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 10 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 11 | innodb/srv_lra_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 12 | innodb/srv_akp_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 18 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 248 bytes |
| 19 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 20 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 21 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 22 | innodb/btr_search_sys_toggle_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 32 | innodb/dict_persist_metadata_table_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 34 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
+-----------+-------------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
831 rows in set (2.48 sec)
```
Conforme mencionado anteriormente, o valor do ID do thread (`thd_id`) aqui pode se referir a threads em segundo plano do servidor ou a conexões do banco de dados. Se quiser associar valores de ID de thread a IDs de conexão de banco de dados, você poderá usar a tabela `performance_schema.threads` ou a visualização `sys.processlist`, em que `conn_id` é o ID de conexão.
```
mysql> SELECT thd_id,conn_id,user,db,command,state,time,last_wait FROM sys.processlist WHERE user='reinvent@10.0.4.4';
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| thd_id | conn_id | user | db | command | state | time | last_wait |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
| 590 | 562 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 578 | 550 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 579 | 551 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 580 | 552 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 581 | 553 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 582 | 554 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 583 | 555 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 584 | 556 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 585 | 557 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 586 | 558 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 587 | 559 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
. .
. .
. .
| 323 | 295 | reinvent@10.0.4.4 | sysbench | Sleep | NULL | 0 | idle |
| 324 | 296 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 325 | 297 | reinvent@10.0.4.4 | sysbench | Execute | closing tables | 0 | wait/io/redo_log_flush |
| 326 | 298 | reinvent@10.0.4.4 | sysbench | Execute | updating | 0 | wait/io/table/sql/handler |
| 438 | 410 | reinvent@10.0.4.4 | sysbench | Execute | System lock | 0 | wait/lock/table/sql/handler |
| 280 | 252 | reinvent@10.0.4.4 | sysbench | Sleep | starting | 0 | wait/io/socket/sql/client_connection |
| 98 | 70 | reinvent@10.0.4.4 | sysbench | Query | freeing items | 0 | NULL |
+--------+---------+-------------------+----------+---------+----------------+------+-------------------------------------------------+
804 rows in set (5.51 sec)
```
Agora interrompemos a workload `sysbench`, que encerra as conexões e libera a memória. Conferindo novamente os eventos, podemos confirmar que a memória foi liberada, mas `high_alloc` ainda informa qual é o limite máximo. A coluna `high_alloc` pode ser muito útil na identificação de pequenos picos no uso da memória, na qual talvez você não consiga identificar imediatamente o uso de `current_alloc`, o qual mostra apenas a memória atualmente alocada.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 512823 | 4.91 GiB | 10.04 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
Se quiser redefinir `high_alloc`, você poderá truncar as tabelas de resumo de memória do `performance_schema`, mas isso redefinirá toda a instrumentação da memória. Para ter mais informações, consulte [Performance Schema general table characteristics](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-table-characteristics.html) na documentação do MySQL.
No exemplo a seguir, podemos ver que `high_alloc` é redefinido após o truncamento.
```
mysql> TRUNCATE `performance_schema`.`memory_summary_global_by_event_name`;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM sys.memory_global_by_current_bytes WHERE event_name='memory/sql/Prepared_statement::main_mem_root' LIMIT 10;
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/sql/Prepared_statement::main_mem_root | 17 | 253.80 KiB | 14.93 KiB | 17 | 253.80 KiB | 14.93 KiB |
+----------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
1 row in set (0.00 sec)
```
## Exemplo 2: Picos transitórios de memória
Outra ocorrência comum são pequenos picos no uso da memória em um servidor de banco de dados. Podem ser quedas periódicas na memória liberável que são difíceis de solucionar usando `current_alloc` em `sys.memory_global_by_current_bytes`, pois a memória já foi liberada.
**nota**
Se as estatísticas do Esquema de Performance tiverem sido redefinidas ou a instância do banco de dados tiver sido reiniciada, essas informações não estarão disponíveis no `sys` nem no p`erformance_schema`. Para reter essas informações, recomendamos configurar a coleta de métricas externas.
O grafo a seguir da métrica `os.memory.free` no Monitoramento Avançado mostra breves picos de sete segundos no uso da memória. O Monitoramento Avançado permite monitorar em intervalos de até um segundo, o que é perfeito para detectar picos transitórios como esses.
![\[Gráfico mostrando picos transitórios de uso de memória ao longo do tempo com padrão periódico, indicando possíveis problemas de gerenciamento de memória.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ams-free-memory-spikes.png)
Para ajudar a diagnosticar a causa do uso da memória aqui, podemos usar uma combinação de `high_alloc` nas visualizações resumidas de memória `sys` e [tabelas de resumo de declarações do Esquema de Performance](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) para tentar identificar sessões e conexões incorretas.
Como esperado, visto que o uso de memória atualmente não é alto, não podemos ver nenhum problema grave na visualização do esquema `sys` abaixo de `current_alloc`.
```
mysql> SELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| event_name | current_count | current_alloc | current_avg_alloc | high_count | high_alloc | high_avg_alloc |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
| memory/innodb/hash0hash | 4 | 79.07 MiB | 19.77 MiB | 4 | 79.07 MiB | 19.77 MiB |
| memory/innodb/os0event | 439372 | 60.34 MiB | 144 bytes | 439372 | 60.34 MiB | 144 bytes |
| memory/performance_schema/events_statements_summary_by_digest | 1 | 40.28 MiB | 40.28 MiB | 1 | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 3 | 16.00 MiB | 5.33 MiB | 3 | 16.00 MiB | 5.33 MiB |
| memory/performance_schema/events_statements_history_long | 1 | 14.34 MiB | 14.34 MiB | 1 | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 257 | 13.07 MiB | 52.06 KiB | 257 | 13.07 MiB | 52.06 KiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 1 | 11.81 MiB | 11.81 MiB | 1 | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.digest_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 1 | 9.77 MiB | 9.77 MiB | 1 | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------+---------------+-------------------+------------+------------+----------------+
10 rows in set (0.01 sec)
```
Expandindo a visualização para ordenar por `high_alloc`, agora podemos ver que o componente `memory/temptable/physical_ram` é um candidato muito bom aqui. No momento de pico, consumiu 515,00 MiB.
Como o próprio nome sugere, `memory/temptable/physical_ram` instrumenta o uso de memória para o mecanismo de armazenamento `TEMP` no MySQL, que foi introduzido no MySQL 8.0. Para ter mais informações sobre como o MySQL usa tabelas temporárias, consulte [Internal temporary table use in MySQL](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html) na documentação do MySQL.
**nota**
Estamos usando `sys.x$memory_global_by_current_bytes` neste exemplo.
```
mysql> SELECT event_name, format_bytes(current_alloc) AS "currently allocated", sys.format_bytes(high_alloc) AS "high-water mark"
FROM sys.x$memory_global_by_current_bytes ORDER BY high_alloc DESC LIMIT 10;
+-----------------------------------------------------------------------------+---------------------+-----------------+
| event_name | currently allocated | high-water mark |
+-----------------------------------------------------------------------------+---------------------+-----------------+
| memory/temptable/physical_ram | 4.00 MiB | 515.00 MiB |
| memory/innodb/hash0hash | 79.07 MiB | 79.07 MiB |
| memory/innodb/os0event | 63.95 MiB | 63.95 MiB |
| memory/performance_schema/events_statements_summary_by_digest | 40.28 MiB | 40.28 MiB |
| memory/mysys/KEY_CACHE | 16.00 MiB | 16.00 MiB |
| memory/performance_schema/events_statements_history_long | 14.34 MiB | 14.34 MiB |
| memory/performance_schema/events_errors_summary_by_thread_by_error | 13.07 MiB | 13.07 MiB |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name | 11.81 MiB | 11.81 MiB |
| memory/performance_schema/events_statements_summary_by_digest.digest_text | 9.77 MiB | 9.77 MiB |
| memory/performance_schema/events_statements_history_long.sql_text | 9.77 MiB | 9.77 MiB |
+-----------------------------------------------------------------------------+---------------------+-----------------+
10 rows in set (0.00 sec)
```
Em [Exemplo 1: Alto uso contínuo de memória](#ams-workload-memory.example1), conferimos o uso atual da memória para cada conexão com o objetivo de determinar qual delas é responsável pelo uso da memória em questão. Neste exemplo, a memória já está liberada; portanto, conferir o uso da memória nas conexões atuais não é útil.
Para nos aprofundarmos e encontrarmos as declarações, os usuários e os hosts com problemas, usamos o Esquema de Performance. O Esquema de Performance contém várias tabelas de resumo de declarações que são divididas por dimensões diferentes, como nome do evento, resumo de declarações, host, thread e usuário. Cada visualização possibilitará que você se aprofunde nos locais em que determinadas declarações estão sendo executadas e o que estão fazendo. Esta seção se concentra em `MAX_TOTAL_MEMORY`, mas é possível encontrar mais informações sobre todas as colunas disponíveis na documentação [Performance Schema statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html).
```
mysql> SHOW TABLES IN performance_schema LIKE 'events_statements_summary_%';
+------------------------------------------------------------+
| Tables_in_performance_schema (events_statements_summary_%) |
+------------------------------------------------------------+
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_digest |
| events_statements_summary_by_host_by_event_name |
| events_statements_summary_by_program |
| events_statements_summary_by_thread_by_event_name |
| events_statements_summary_by_user_by_event_name |
| events_statements_summary_global_by_event_name |
+------------------------------------------------------------+
7 rows in set (0.00 sec)
```
Primeiro, conferimos `events_statements_summary_by_digest` para ver `MAX_TOTAL_MEMORY`.
Com base nesses dados, você pode deduzir o seguinte:
+ A consulta com `20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a` resumido parece ser uma boa candidata para esse uso de memória. A `MAX_TOTAL_MEMORY` é 537450710, que corresponde ao limite máximo que vimos no evento `memory/temptable/physical_ram` em `sys.x$memory_global_by_current_bytes`.
+ Houve quatro execuções (`COUNT_STAR`); a primeira em 2024-03-26 04:08:34.943256 e a última em 2024-03-26 04:43:06.998310.
```
mysql> SELECT SCHEMA_NAME,DIGEST,COUNT_STAR,MAX_TOTAL_MEMORY,FIRST_SEEN,LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest ORDER BY MAX_TOTAL_MEMORY DESC LIMIT 5;
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| SCHEMA_NAME | DIGEST | COUNT_STAR | MAX_TOTAL_MEMORY | FIRST_SEEN | LAST_SEEN |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
| sysbench | 20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a | 4 | 537450710 | 2024-03-26 04:08:34.943256 | 2024-03-26 04:43:06.998310 |
| NULL | f158282ea0313fefd0a4778f6e9b92fc7d1e839af59ebd8c5eea35e12732c45d | 4 | 3636413 | 2024-03-26 04:29:32.712348 | 2024-03-26 04:36:26.269329 |
| NULL | 0046bc5f642c586b8a9afd6ce1ab70612dc5b1fd2408fa8677f370c1b0ca3213 | 2 | 3459965 | 2024-03-26 04:31:37.674008 | 2024-03-26 04:32:09.410718 |
| NULL | 8924f01bba3c55324701716c7b50071a60b9ceaf17108c71fd064c20c4ab14db | 1 | 3290981 | 2024-03-26 04:31:49.751506 | 2024-03-26 04:31:49.751506 |
| NULL | 90142bbcb50a744fcec03a1aa336b2169761597ea06d85c7f6ab03b5a4e1d841 | 1 | 3131729 | 2024-03-26 04:15:09.719557 | 2024-03-26 04:15:09.719557 |
+-------------+------------------------------------------------------------------+------------+------------------+----------------------------+----------------------------+
5 rows in set (0.00 sec)
```
Agora que conhecemos o resumo de problemas, podemos ver mais detalhes, como o texto da consulta, o usuário que a executou e onde ela foi executada. Com base no texto resumido exibido, podemos ver que essa é uma expressão de tabela comum (CTE) que cria quatro tabelas temporárias e executa quatro verificações de tabela, o que é muito ineficiente.
```
mysql> SELECT SCHEMA_NAME,DIGEST_TEXT,QUERY_SAMPLE_TEXT,MAX_TOTAL_MEMORY,SUM_ROWS_SENT,SUM_ROWS_EXAMINED,SUM_CREATED_TMP_TABLES,SUM_NO_INDEX_USED
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST='20676ce4a690592ff05debcffcbc26faeb76f22005e7628364d7a498769d0c4a'\G;
*************************** 1. row ***************************
SCHEMA_NAME: sysbench
DIGEST_TEXT: WITH RECURSIVE `cte` ( `n` ) AS ( SELECT ? FROM `sbtest1` UNION ALL SELECT `id` + ? FROM `sbtest1` ) SELECT * FROM `cte`
QUERY_SAMPLE_TEXT: WITH RECURSIVE cte (n) AS ( SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte
MAX_TOTAL_MEMORY: 537450710
SUM_ROWS_SENT: 80000000
SUM_ROWS_EXAMINED: 80000000
SUM_CREATED_TMP_TABLES: 4
SUM_NO_INDEX_USED: 4
1 row in set (0.01 sec)
```
Para ter mais informações sobre a tabela `events_statements_summary_by_digest` e outras tabelas de resumo de declarações do Esquema de Performance, consulte [Statement summary tables](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html) na documentação do MySQL.
Também é possível executar uma declaração [EXPLAIN](https://dev.mysql.com/doc/refman/8.0/en/explain.html) ou [EXPLAIN ANALYZE](https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze) para ver mais detalhes.
**nota**
`EXPLAIN ANALYZE` pode fornecer mais informações do que `EXPLAIN`, mas também executa a consulta; portanto, tenha cuidado.
```
-- EXPLAIN
mysql> EXPLAIN WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte;
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
| 1 | PRIMARY | | NULL | ALL | NULL | NULL | NULL | NULL | 19221520 | 100.00 | NULL |
| 2 | DERIVED | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
| 3 | UNION | sbtest1 | NULL | index | NULL | k_1 | 4 | NULL | 9610760 | 100.00 | Using index |
+----+-------------+------------+------------+-------+---------------+------+---------+------+----------+----------+-------------+
3 rows in set, 1 warning (0.00 sec)
-- EXPLAIN format=tree
mysql> EXPLAIN format=tree WITH RECURSIVE cte (n) AS (SELECT 1 FROM sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
-> Index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6)
1 row in set (0.00 sec)
-- EXPLAIN ANALYZE
mysql> EXPLAIN ANALYZE WITH RECURSIVE cte (n) AS (SELECT 1 from sbtest1 UNION ALL SELECT id + 1 FROM sbtest1) SELECT * FROM cte\G;
*************************** 1. row ***************************
EXPLAIN: -> Table scan on cte (cost=4.11e+6..4.35e+6 rows=19.2e+6) (actual time=6666..9201 rows=20e+6 loops=1)
-> Materialize union CTE cte (cost=4.11e+6..4.11e+6 rows=19.2e+6) (actual time=6666..6666 rows=20e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0365..2006 rows=10e+6 loops=1)
-> Covering index scan on sbtest1 using k_1 (cost=1.09e+6 rows=9.61e+6) (actual time=0.0311..2494 rows=10e+6 loops=1)
1 row in set (10.53 sec)
```
Mas quem a executou? Podemos ver no Esquema de Performance que o usuário `destructive_operator` tinha 537450710 de `MAX_TOTAL_MEMORY`, que novamente corresponde aos resultados anteriores.
**nota**
O Esquema de Performance é armazenado na memória; portanto, não deve ser considerado a única fonte de auditoria. Se você precisar manter um histórico das instruções executadas e dos usuários que as executaram, recomendamos habilitar o [Aurora Advanced Auditing](AuroraMySQL.Auditing.md). Se você também precisar manter informações sobre o uso da memória, recomendamos configurar o monitoramento para exportar e armazenar esses valores.
```
mysql> SELECT USER,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_user_by_event_name
ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+----------------------+---------------------------+------------+------------------+
| USER | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+----------------------+---------------------------+------------+------------------+
| destructive_operator | statement/sql/select | 4 | 537450710 |
| rdsadmin | statement/sql/select | 4172 | 3290981 |
| rdsadmin | statement/sql/show_tables | 2 | 3615821 |
| rdsadmin | statement/sql/show_fields | 2 | 3459965 |
| rdsadmin | statement/sql/show_status | 75 | 1914976 |
+----------------------+---------------------------+------------+------------------+
5 rows in set (0.00 sec)
mysql> SELECT HOST,EVENT_NAME,COUNT_STAR,MAX_TOTAL_MEMORY FROM performance_schema.events_statements_summary_by_host_by_event_name
WHERE HOST != 'localhost' AND COUNT_STAR>0 ORDER BY MAX_CONTROLLED_MEMORY DESC LIMIT 5;
+------------+----------------------+------------+------------------+
| HOST | EVENT_NAME | COUNT_STAR | MAX_TOTAL_MEMORY |
+------------+----------------------+------------+------------------+
| 10.0.8.231 | statement/sql/select | 4 | 537450710 |
+------------+----------------------+------------+------------------+
1 row in set (0.00 sec)
```
## Exemplo 3: A memória liberável cai continuamente e não é recuperada
O mecanismo de banco de dados InnoDB emprega uma variedade de eventos especializados de rastreamento de memória para diferentes componentes. Esses eventos específicos permitem o rastreamento granular do uso da memória nos principais subsistemas do InnoDB, por exemplo:
+ `memory/innodb/buf0buf`: dedicado ao monitoramento das alocações de memória para o grupo de buffers do InnoDB.
+ `memory/innodb/ibuf0ibuf`: rastreia especificamente as alterações de memória relacionadas ao buffer de alterações do InnoDB.
Para identificar os principais consumidores de memória, podemos consultar `sys.memory_global_by_current_bytes`:
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.28 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
Os resultados mostram que `memory/innodb/memory` é o maior consumidor, usando 5,28 GiB de memória alocada atualmente. Esse evento serve como uma categoria para alocações de memória em vários componentes do InnoDB não associados a eventos de espera mais específicos, como `memory/innodb/buf0buf` mencionado anteriormente.
Tendo estabelecido que os componentes do InnoDB são os principais consumidores de memória, podemos nos aprofundar nas especificidades usando o seguinte comando do MySQL:
```
SHOW ENGINE INNODB STATUS \G;
```
O comando [SHOW ENGINE INNODB STATUS](https://dev.mysql.com/doc/refman/8.4/en/show-engine.html) fornece um relatório de status abrangente do mecanismo de armazenamento do InnoDB, incluindo estatísticas detalhadas de uso de memória de diferentes componentes do InnoDB. Ele pode ajudar a identificar quais estruturas ou operações específicas do InnoDB estão consumindo mais memória. Para obter mais informações, consulte [InnoDB in-memory structures](https://dev.mysql.com/doc/refman/8.0/en/innodb-in-memory-structures.html) na documentação do MySQL.
Analisando a seção `BUFFER POOL AND MEMORY` do relatório de status do InnoDB, vemos que 5.051.647.748 bytes (4,7 GiB) são alocados ao [cache de objetos do dicionário](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-object-cache.html), que representa 89% da memória rastreada por `memory/innodb/memory`.
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5051647748
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
O cache de objetos do dicionário é um cache global compartilhado que armazena objetos de dicionário de dados acessados anteriormente na memória para permitir a reutilização de objetos e melhorar o desempenho. A alta alocação de memória para o cache de objetos do dicionário sugere um grande número de objetos do banco de dados no cache do dicionário de dados.
Agora que sabemos que o cache do dicionário de dados é o principal consumidor, vamos inspecionar o cache do dicionário de dados em busca de tabelas abertas. Para encontrar o número de tabelas no cache de definição de tabela, consulte a variável de status global [open\$1table\$1definitions](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html#statvar_Open_table_definitions).
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 20000 |
+------------------------+-------+
1 row in set (0.00 sec)
```
Para obter mais informações, consulte [How MySQL opens and closes tables](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html) na documentação do MySQL.
É possível limitar o número de definições de tabela no cache do dicionário de dados limitando o parâmetro `table_definition_cache` no grupo de parâmetros do cluster de banco de dados ou da instância de banco de dados. Para o Aurora MySQL, esse valor serve como um limite flexível para o número de tabelas no cache de definição de tabela. O valor padrão depende da classe da instância e é definido da seguinte forma:
```
LEAST({DBInstanceClassMemory/393040}, 20000)
```
Quando o número de tabelas excede o limite `table_definition_cache`, um mecanismo de menos usados recentemente (LRU) remove as tabelas do cache. No entanto, as tabelas envolvidas em relações de chave externa não são colocadas na lista de LRU, impedindo sua remoção.
Em nosso cenário atual, executamos [FLUSH TABLES](https://dev.mysql.com/doc/refman/8.4/en/flush.html) para limpar o cache de definição de tabela. Essa ação resulta em uma queda significativa na variável de status global [Open\$1table\$1definitions](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Open_table_definitions), de 20.000 para 12, conforme mostrado aqui:
```
mysql> show global status like 'open_table_definitions';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| Open_table_definitions | 12 |
+------------------------+-------+
1 row in set (0.00 sec)
```
Apesar dessa redução, observamos que a alocação de memória para `memory/innodb/memory` permanece alta em 5,18 GiB, e a memória do dicionário alocada também permanece inalterada. Isso fica evidente nos seguintes resultados da consulta:
```
mysql> SELECT event_name,current_alloc FROM sys.memory_global_by_current_bytes LIMIT 10;
+-----------------------------------------------------------------+---------------+
| event_name | current_alloc |
+-----------------------------------------------------------------+---------------+
| memory/innodb/memory | 5.18 GiB |
| memory/performance_schema/table_io_waits_summary_by_index_usage | 495.00 MiB |
| memory/performance_schema/table_shares | 488.00 MiB |
| memory/sql/TABLE_SHARE::mem_root | 388.95 MiB |
| memory/innodb/std | 226.88 MiB |
| memory/innodb/fil0fil | 198.49 MiB |
| memory/sql/binlog_io_cache | 128.00 MiB |
| memory/innodb/mem0mem | 96.82 MiB |
| memory/innodb/dict0dict | 96.76 MiB |
| memory/performance_schema/rwlock_instances | 88.00 MiB |
+-----------------------------------------------------------------+---------------+
10 rows in set (0.00 sec)
```
```
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 0
Dictionary memory allocated 5001599639
Buffer pool size 170512
Free buffers 142568
Database pages 27944
Old database pages 10354
Modified db pages 6
Pending reads 0
```
Esse uso persistentemente alto de memória pode ser atribuído a tabelas envolvidas em relações de chave externa. Essas tabelas não são colocadas na lista de LRU para remoção, explicando por que a alocação de memória permanece alta mesmo depois de limpar o cache de definição de tabela.
Para resolver esse problema:
1. Revise e otimize seu esquema de banco de dados, particularmente as relações de chave externa.
1. Considere migrar para uma classe de instância de banco de dados maior que tenha mais memória para acomodar seus objetos de dicionário.
Seguindo essas etapas e entendendo os padrões de alocação de memória, é possível gerenciar melhor o uso de memória na instância de banco de dados do Aurora MySQL e evitar possíveis problemas de desempenho devido à pressão de memória.
# Solucionar problemas de falta de memória em bancos de dados do Aurora MySQL
O parâmetro de nível de instância `aurora_oom_response` do Aurora MySQL pode habilitar a instância de banco de dados a monitorar a memória de sistema consumida por várias instruções e conexões. Se o sistema estiver com pouca memória, ele poderá executar uma lista de ações para tentar liberar essa memória. Ele faz isso em uma tentativa de evitar uma reinicialização do banco de dados devido a problemas de falta de memória (OOM). O parâmetro no nível da instância usa uma string de ações separadas por vírgula que uma instância de banco de dados realiza quando sua memória está baixa. O parâmetro `aurora_oom_response` é compatível com o Aurora MySQL versões 2 e 3.
Os valores a seguir e as combinações deles podem ser usados para o parâmetro `aurora_oom_response`. Uma string vazia significa que não há ações a serem realizadas e desativa efetivamente o recurso, deixando o banco de dados propenso a reinicializações de OOM.
+ `decline`: recusa novas consultas quando a instância de banco de dados tem pouca memória.
+ `kill_connect`: fecha as conexões de banco de dados que estão consumindo grande quantidade de memória e encerra as transações atuais e as declarações de linguagem de definição de dados (DDL). Essa resposta não é compatível com o Aurora MySQL versão 2.
Consulte mais informações em [KILL statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) na documentação do MySQL.
+ `kill_query`: encerra as consultas em ordem decrescente de consumo da memória até a memória da instância superar o limite mínimo. As instruções DDL não são encerradas.
Consulte mais informações em [KILL statement](https://dev.mysql.com/doc/refman/8.0/en/kill.html) na documentação do MySQL.
+ `print`: imprime apenas as consultas que consomem uma grande quantidade de memória.
+ `tune` – ajusta os caches de tabela internos para liberar parte da memória de volta para o sistema. O Aurora MySQL diminui a memória usada para caches, como `table_open_cache` e `table_definition_cache` em condições de pouca memória. Por fim, o Aurora MySQL define seu uso de memória de volta ao normal quando o sistema deixa de ter pouca memória.
Consulte mais informações em [table\$1open\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_open_cache) e [table\$1definition\$1cache](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_definition_cache) na documentação do MySQL.
+ `tune_buffer_pool`: diminui o tamanho do pool de buffer para liberar alguma memória e disponibilizá-la para o servidor de banco de dados processar conexões. Essa resposta é compatível com o Aurora MySQL versão 3.06 e posterior.
É necessário emparelhar `tune_buffer_pool` com `kill_query` ou `kill_connect` no valor do parâmetro `aurora_oom_response`. Caso contrário, o redimensionamento do pool de buffer não ocorrerá, mesmo quando você incluir `tune_buffer_pool` no valor do parâmetro.
Nas versões do Aurora MySQL anteriores à 3.06, para classes de instância de banco de dados com memória menor ou igual a 4 GiB, quando a instância está sob pressão de memória, as ações padrão incluem `print`, `tune`, `decline` e `kill_query`. Para classes de instância de banco de dados com memória maior que 4 GiB, o valor do parâmetro ficará vazio por padrão (desabilitado).
No Aurora MySQL versão 3.06 e posterior, para classes de instância de banco de dados com memória menor ou igual a 4 GiB, o Aurora MySQL também fecha as conexões que mais consomem memória (`kill_connect`). Em relação a classes de instância de banco de dados com memória maior que 4 GiB, o valor do parâmetro padrão é `print`.
No Aurora MySQL versão 3.09 e posterior, para classes de instância de banco de dados com memória superior a 4 GiB, o valor do parâmetro padrão é `print,decline,kill_connect`.
Se você costuma ter problemas de falta de memória, o uso da memória pode ser monitorado usando [tabelas de resumo de memória](https://dev.mysql.com/doc/refman/8.3/en/performance-schema-memory-summary-tables.html) quando `performance_schema` estiver habilitado.
Em relação a métricas do Amazon CloudWatch relacionadas a OOM, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Em relação a variáveis de status global relacionadas a OOM, consulte [Variáveis de status globais do Aurora MySQL](AuroraMySQL.Reference.GlobalStatusVars.md).
# Registro em log de bancos de dados do Aurora MySQL
Os logs do Aurora MySQL fornecem informações essenciais sobre a atividade e os erros do banco de dados. Ao habilitar esses logs, é possível identificar e solucionar problemas, entender o desempenho do banco de dados e auditar a atividade do banco de dados. Recomendamos que você habilite esses logs para todas as instâncias de banco de dados do Aurora MySQL para garantir o desempenho e a disponibilidade ideais dos bancos de dados. Os tipos de logs a seguir podem ser habilitados. Cada log contém informações específicas que podem levar à descoberta de impactos no processamento do banco de dados.
+ Erro: o Aurora MySQL grava no log de erros apenas na inicialização, no desligamento e quando encontra erros. Uma instância de banco de dados pode passar horas ou dias sem novas entradas gravadas no log de erros. Se você não vir nenhuma entrada recente, é porque o servidor não encontrou nenhum erro que tenha gerado uma entrada de log. O log de erros está habilitado por padrão. Para ter mais informações, consulte [Logs de erro do Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Errorlog).
+ Geral: o log geral fornece informações detalhadas sobre a atividade do banco de dados, incluindo todas as instruções SQL executadas pelo mecanismo do banco de dados. Consulte mais informações sobre como habilitar o registro em log geral e definir parâmetros de registro em log em [Logs gerais e de consultas lentas do Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) e [The general query log](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) na documentação do MySQL.
**nota**
Os logs gerais podem se tornar muito grandes e consumir seu armazenamento. Para ter mais informações, consulte [Alternância e retenção de logs do Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.AMS.LogFileSize.retention).
+ Consulta lenta: um log de consulta lenta consiste em instruções SQL que levam mais de [long\$1query\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_long_query_time) segundos para serem executadas e exigem que, no mínimo, [min\$1examined\$1row\$1limit](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_min_examined_row_limit) linhas sejam examinadas. É possível usar o log de consulta lenta para encontrar consultas que demoram muito para serem executadas e, portanto, são candidatas à otimização.
O valor padrão para `long_query_time` é 10 segundos. Recomendamos que você comece com um valor alto para identificar as consultas mais lentas e, depois, vá ajustando os valores seguintes.
Também é possível usar parâmetros relacionados, como `log_slow_admin_statements` e `log_queries_not_using_indexes`. Compare `rows_examined` com `rows_returned`. Se `rows_examined` for muito maior que `rows_returned`, então essas consultas podem estar bloqueadas.
No Aurora MySQL versão 3, é possível habilitar `log_slow_extra` para consultar mais detalhes. Consulte mais informações em [Slow query log contents](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html#slow-query-log-contents) na documentação do MySQL. Também é possível modificar `long_query_time` no nível da sessão para depurar a execução da consulta de forma interativa, o que é bastante útil se `log_slow_extra` estiver habilitado globalmente.
Consulte mais informações sobre como habilitar o registro em log geral e definir parâmetros de registro em log em [Logs gerais e de consultas lentas do Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md#USER_LogAccess.MySQL.Generallog) e [The general query log](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) na documentação do MySQL.
+ Auditoria: o log de auditoria monitora e registra a atividade do banco de dados. O registro em log de auditoria do Aurora MySQL é chamado de Auditoria avançada. Para habilitar a Auditoria avançada, defina determinados parâmetros de cluster de banco de dados. Para ter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
+ Binário: o log binário (binlog) contém eventos que descrevem alterações no banco de dados, como operações de criação de tabelas e alterações nos dados da tabela. Ele também contém eventos para instruções que poderiam ter feito alterações (por exemplo, uma instrução [DELETE](https://dev.mysql.com/doc/refman/8.0/en/delete.html) que não correspondia a nenhuma linha), a menos que o registro em log baseado em linhas seja usado. O log binário também contém informações sobre quanto tempo cada instrução levou para os dados atualizados.
A execução de um servidor com os logs binários habilitados torna o desempenho um pouco mais baixo. No entanto, os benefícios do log binário em permitir que você configure a replicação e as operações de restauração geralmente superam essa pequena diminuição no desempenho.
**nota**
O Aurora MySQL não exige registro em log binário para operações de restauração.
Consulte mais informações sobre como habilitar o registro em log binário e definir o formato do binlog em [Configurar o registro em log binário do Aurora MySQL para bancos de dados single-AZ](USER_LogAccess.MySQL.BinaryFormat.md) e [The binary log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) na documentação do MySQL.
É possível publicar logs gerais, de erro, de consultas lentas, de consulta e de auditoria no Amazon CloudWatch Logs. Para ter mais informações, consulte [Publicação de logs de banco de dados no Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
Outra ferramenta útil para resumir arquivos de log gerais, binários e de consultas lentas é [pt-query-digest](https://docs.percona.com/percona-toolkit/pt-query-digest.html).
# Solucionar problemas de conexão para bancos de dados do Aurora MySQL e
Garantir conectividade confiável entre as aplicações e a instância de banco de dados do RDS é essencial para o bom funcionamento das workloads. No entanto, problemas de conectividade podem surgir como consequência de vários fatores, como configurações de rede, problemas de autenticação ou restrições de recursos. Este guia tem como objetivo fornecer uma abordagem abrangente para solucionar problemas de conectividade com o Aurora MySQL e o .
**Contents**
+ [Identificar problemas de conectividade de banco de dados do Aurora MySQL e](#mysql-dbconn-identify)
+ [Coletar dados sobre problemas de conectividade do Aurora MySQL e](#mysql-dbconn-gather)
+ [Monitorar conexões de banco de dados do Aurora MySQL e](#mysql-dbconn-monitor)
+ [Monitoramento adicional do Aurora MySQL](#mysql-dbconn-monitor-ams)
+ [Códigos de erro de conectividade do Aurora MySQL e](#mysql-dbconn-errors)
+ [Recomendações de ajuste de parâmetros do Aurora MySQL e](#mysql-dbconn-params)
+ [Exemplos de solução de problemas de conexão de banco de dados do Aurora MySQL e](#mysql-dbconn-examples)
+ [Exemplo 1: solução de problemas em tentativas de conexão malsucedidas](#mysql-dbconn-example1)
+ [Exemplo 2: solução de problemas de desconexões anormais do cliente](#mysql-dbconn-example2)
+ [Exemplo 3: solução de problemas em tentativas de conexão malsucedidas do IAM](#mysql-dbconn-example3)
## Identificar problemas de conectividade de banco de dados do Aurora MySQL e
Identificar a categoria específica do problema de conectividade pode ajudar a reduzir as possíveis causas e orientar o processo de solução de problemas. Cada categoria pode exigir abordagens e técnicas diferentes para diagnóstico e solução. Os problemas de conectividade do banco de dados podem ser amplamente classificados nas categorias a seguir.
**Erros e exceções de conexão**
Erros e exceções de conexão podem ocorrer por vários motivos, como strings de conexão incorretas, falhas de autenticação, interrupções na rede ou problemas no servidor do banco de dados. As causas podem incluir parâmetros de conexão configurados incorretamente, credenciais inválidas, interrupções na rede, falhas ou reinicializações do servidor de banco de dados. Grupos de segurança configurados incorretamente, configurações de nuvem privada virtual (VPC), listas de controle de acesso (ACLs) de rede e tabelas de rotas associadas a sub-redes também podem causar problemas de conexão.
**Limite de conexão atingido**
Este problema ocorre quando o número de conexões simultâneas com o servidor de banco de dados excede o limite máximo permitido. Os servidores de banco de dados geralmente têm um limite máximo de conexão configurável definido pelo parâmetro max\$1connections nos clusters e nos grupos de parâmetros da instância. Quando um limite de conexão é aplicado, o servidor de banco de dados garante que ele tenha recursos suficientes (por exemplo, memória, CPU e identificadores de arquivos) para lidar com as conexões existentes de maneira eficiente e oferecer uma performance aceitável. As causas podem incluir vazamentos de conexão na aplicação, agrupamento ineficiente de conexões ou um aumento inesperado nas solicitações de conexão.
**Tempos limite de conexão**
Os tempos limite de conexão ocorrem quando a aplicação cliente não consegue estabelecer uma conexão com o servidor do banco de dados dentro de um período de tempo limite especificado. As causas comuns são problemas de rede, sobrecarga do servidor, regras de firewall e configurações de conexão configuradas incorretamente.
**Tempos limite de inatividade da conexão**
Conexões ociosas que permanecem inativas por um período prolongado podem ser fechadas automaticamente pelo servidor de banco de dados para conservar recursos. Esse tempo limite geralmente é configurável usando o `wait_timeout` e o `interactive_timeout parameters`, e deve ser ajustado com base nos padrões de uso da conexão da aplicação. As causas podem incluir a lógica da aplicação que deixa as conexões ociosas por longos períodos ou o gerenciamento inadequado da conexão.
**Desconexão intermitente das conexões existentes**
Esta classe de erros se refere a um cenário em que as conexões estabelecidas entre uma aplicação cliente e o banco de dados são encerradas ou desconectadas inesperadamente em intervalos irregulares, apesar de estarem ativas e em uso. Essas desconexões ocorrem de maneira intermitente, o que significa que acontecem em intervalos irregulares e não consistentes. As causas podem ser as seguintes:
+ Problemas do servidor de banco de dados, como reinicializações ou failovers
+ Processamento inadequado da conexão com a aplicação
+ Problemas de balanceamento de carga e de proxy
+ Instabilidade da rede
+ Problemas com componentes ou middleware de terceiros envolvidos no caminho da conexão
+ Tempos limite de execução da consulta
+ Restrições de recursos no lado do servidor ou do cliente
Identificar a causa raiz por meio de monitoramento, registro em log e análise abrangentes é crucial, enquanto a implementação de mecanismos adequados de tratamento de erros, agrupamento de conexões e novas tentativas pode ajudar a mitigar o impacto dessas desconexões intermitentes na funcionalidade e na experiência do usuário da aplicação.
## Coletar dados sobre problemas de conectividade do Aurora MySQL e
A coleta de dados abrangentes relacionados aos componentes da aplicação, do banco de dados, da rede e da infraestrutura é essencial para solucionar com eficácia os problemas de conectividade entre uma aplicação e um banco de dados do Aurora MySQL ou . Ao coletar logs, configurações e informações de diagnóstico relevantes, é possível ter insights valiosos que podem ajudar a identificar a causa básica dos problemas de conectividade e orientar você para uma solução adequada.
Logs e configurações de rede, como regras de grupos de segurança, configurações de VPC e tabelas de rotas, são essenciais para identificar possíveis gargalos ou configurações incorretas relacionadas à rede que possam estar impedindo a aplicação de estabelecer uma conexão bem-sucedida com o banco de dados. Ao analisar esses componentes de rede, é possível garantir que as portas necessárias estejam abertas, os endereços IP sejam permitidos e as configurações de roteamento estejam definidas corretamente.
**Carimbos de data/hora**
Registre os carimbos de data/hora exatos quando os problemas de conectividade ocorrerem. Isso pode ajudar a identificar padrões ou correlacionar os problemas com outros eventos ou atividades.
**Logs de mecanismo de banco de dados**
Além dos logs gerais de banco de dados, revise os logs do mecanismo de banco de dados (por exemplo, o log de erros do MySQL e o log de consultas lentas) em busca de informações ou erros relevantes que possam estar relacionados aos problemas intermitentes de conectividade. Para obter mais informações, consulte [Registro em log de bancos de dados do Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Logs da aplicação cliente**
Colete logs detalhados das aplicações cliente que se conectam ao banco de dados. Os logs da aplicação fornecem visibilidade das tentativas de conexão, dos erros e de qualquer informação relevante do ponto de vista da aplicação, o que pode revelar problemas relacionados às strings de conexão, às credenciais de autenticação ou ao tratamento da conexão no nível da aplicação.
Os logs do banco de dados, por outro lado, oferecem insights sobre erros do lado do banco de dados, consultas lentas ou eventos que podem estar contribuindo com os problemas de conectividade. Para obter mais informações, consulte [Registro em log de bancos de dados do Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
**Variáveis do ambiente do cliente**
Verifique se alguma variável de ambiente ou configuração no lado do cliente pode estar afetando a conexão do banco de dados, como configurações de proxy, configurações de SSL/TLS ou qualquer outra variável relevante.
**Versões da biblioteca do cliente**
Verifique se o cliente está usando as versões mais recentes de todos os drivers, bibliotecas ou frameworks de banco de dados usados para conectividade com o banco de dados. Versões desatualizadas podem ter problemas conhecidos ou problemas de compatibilidade.
**Captura de rede do cliente**
Realize uma captura de rede no lado do cliente usando uma ferramenta, como o Wireshark ou `tcpdump`, durante os momentos em que ocorrerem problemas de conectividade. Isso pode ajudar a identificar quaisquer problemas ou anomalias relacionados à rede no lado do cliente.
**Topologia de rede do cliente**
Entenda a topologia de rede do cliente, inclusive quaisquer firewalls, balanceadores de carga ou outros componentes, como RDS Proxy ou Proxy SQL, que estejam estabelecendo conexões com o banco de dados em vez de o cliente estabelecer conexões diretamente.
**Configurações do sistema operacional do cliente**
Verifique as configurações do sistema operacional do cliente que podem prejudicar a conectividade de rede, como regras de firewall, configurações do adaptador de rede e quaisquer outras configurações relevantes.
**Configuração de agrupamento de conexões**
Se você estiver usando um mecanismo de agrupamento de conexões na aplicação, revise as definições de configuração e monitore as métricas do grupo (por exemplo, conexões ativas, conexões ociosas e tempos limite de conexão) para garantir que o grupo esteja funcionando corretamente. Revise também as configurações do grupo, como os tamanhos mínimo e máximo e as configurações de validação da conexão, para garantir que estejam configuradas corretamente.
**String de conexão**
A string de conexão normalmente inclui parâmetros como nome do host ou endpoint, número da porta, nome do banco de dados e credenciais de autenticação. A análise da string de conexão pode ajudar a identificar possíveis configurações incorretas ou configurações inadequadas que possam estar causando problemas de conectividade. Por exemplo, um nome de host ou um número de porta incorreto pode impedir que o cliente acesse a instância do banco de dados. Já credenciais de autenticação inválidas podem causar falhas de autenticação e rejeições de conexão. Além disso, a string de conexão pode revelar problemas relacionados ao agrupamento de conexões, tempos limite ou outras configurações específicas da conexão que possam contribuir com problemas de conectividade. Fornecer a string de conexão completa usada pela aplicação cliente pode ajudar a identificar qualquer configuração incorreta no cliente.
**Métricas de banco de dados**
Monitore métricas de banco de dados, como uso de CPU, uso de memória e E/S de disco, durante os momentos em que ocorrerem problemas de conectividade. Isso pode ajudar a identificar se a instância de banco de dados está enfrentando problemas de desempenho ou de contenção de recursos.
**DB engine version (Versão do mecanismo de banco de dados)**
Observe a versão do mecanismo de banco de dados do Aurora MySQL e . A AWS lança regularmente atualizações que abordam problemas conhecidos, vulnerabilidades de segurança e introduzem aprimoramentos de desempenho. Portanto, é altamente recomendável que você atualize para as versões mais recentes disponíveis, pois essas atualizações geralmente incluem correções de erros e melhorias relacionadas especificamente à conectividade, ao desempenho e à estabilidade. Fornecer as informações da versão do banco de dados, junto com os outros detalhes coletados, pode ajudar a Suporte a diagnosticar e resolver problemas de conectividade com eficiência.
**Métricas de rede**
Colete métricas de rede, como latência, perda de pacotes e throughput, durante os momentos em que ocorrerem problemas de conectividade. Ferramentas como `ping`, `traceroute` e ferramentas de monitoramento de rede podem ajudar a coletar esses dados.
**Detalhes da origem e do cliente**
Determine os endereços IP dos servidores de aplicações, balanceadores de carga ou quaisquer outros componentes que estejam iniciando as conexões do banco de dados. Isso pode ser um único endereço IP ou um intervalo de endereços IP (notação CIDR). Se a origem for uma instância do Amazon EC2, também é útil analisar o tipo de instância, a zona de disponibilidade, o ID da sub-rede e os grupos de segurança associados à instância, além dos detalhes da interface de rede, como endereço IP privado e endereço IP público.
Ao analisar minuciosamente os dados coletados, é possível identificar configurações incorretas, restrições de recursos, interrupções na rede ou outros problemas subjacentes que estejam causando problemas de conectividade intermitentes ou persistentes. Essas informações permitem que você realize ações específicas, como ajustar configurações, resolver problemas de rede ou lidar com o tratamento de conexões em nível de aplicação.
## Monitorar conexões de banco de dados do Aurora MySQL e
Para monitorar e solucionar problemas de conectividade, use as métricas e os recursos a seguir.
**métricas do CloudWatch**
+ `CPUUtilization`: o alto uso da CPU na instância de banco de dados pode levar à execução lenta de consultas, o que pode resultar em tempos limite de conexão ou rejeições.
+ `DatabaseConnections`: monitore o número de conexões ativas com a instância de banco de dados. Um número alto de conexões próximo ao máximo definido pode indicar possíveis problemas de conectividade ou esgotamento do grupo de conexões.
+ `FreeableMemory`: pouca memória disponível pode causar problemas de desempenho e conectividade devido a restrições de recursos.
+ `NetworkReceiveThroughput` e `NetworkTransmitThroughput`: picos ou quedas incomuns no throughput da rede podem indicar problemas de conectividade ou gargalos na rede.
**Métricas do Performance Insights**
Para solucionar problemas de conectividade no Aurora MySQL e usando o Insights de Performance, analise métricas de banco de dados, como as seguintes:
+ Aborted\$1clients
+ Aborted\$1connects
+ Conexões
+ max\$1connections
+ Threads\$1connected
+ Threads\$1created
+ Threads\$1running
Essas métricas podem ajudar na identificação de gargalos de conexão, detecção de problemas de rede ou de autenticação, otimização do agrupamento de conexões e na garantia do gerenciamento eficiente de threads. Para obter mais informações, consulte [Contadores do Performance Insights para Aurora MySQL](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.Aurora_MySQL).
**Recursos do Insights de Performance**
+ **Carga do banco de dados**: visualize a carga do banco de dados ao longo do tempo e correlacione-a com problemas de conectividade ou degradação do desempenho.
+ **Estatísticas SQL**: analise as estatísticas SQL para identificar consultas ou operações de banco de dados ineficientes que possam contribuir com problemas de conectividade.
+ **Principais consultas**: identifique e analise as consultas que consomem mais recursos, o que pode ajudar a identificar possíveis gargalos de desempenho ou consultas de longa duração que possam estar causando problemas de conectividade.
Ao monitorar essas métricas e utilizar o Insights de Performance, você pode ter visibilidade do desempenho da instância do banco de dados, do uso de recursos e dos possíveis gargalos que possam estar causando problemas de conectividade. Por exemplo:
+ Um alto nível de `DatabaseConnections` próximo ao limite máximo pode indicar esgotamento do agrupamento de conexões ou tratamento inadequado da conexão, causando problemas de conectividade.
+ Alta `CPUUtilization` ou baixa `FreeableMemory` pode indicar restrições de recursos, o que pode causar lentidão na execução de consultas e tempos limite ou rejeições de conexão.
+ Analisar as **Principais consultas** e as **Estatísticas SQL** pode ajudar a identificar consultas ineficientes ou que consomem muitos recursos que possam estar contribuindo com os problemas de conectividade.
Além disso, o monitoramento do CloudWatch Logs e a configuração de alarmes podem ajudar você a identificar e responder proativamente aos problemas de conectividade antes que eles aumentem.
É importante observar que, embora essas métricas e ferramentas possam fornecer insights valiosos, elas devem ser usadas com outras etapas de solução de problemas. Ao analisar também as configurações de rede, as regras do grupo de segurança e o tratamento de conexões no nível da aplicação, é possível diagnosticar e resolver problemas de conectividade de forma abrangente com instâncias de banco de dados do Aurora MySQL e .
### Monitoramento adicional do Aurora MySQL
**métricas do CloudWatch**
+ `AbortedClients`: monitora o número de conexões de cliente que foram fechadas corretamente.
+ `AuroraSlowConnectionHandleCount`: monitora o número de operações lentas de controle de conexão, indicando possíveis problemas de conectividade ou gargalos de desempenho.
+ `AuroraSlowHandshakeCount`: mede o número de operações lentas de handshake, o que também pode ser um indicador de problemas de conectividade.
+ `ConnectionAttempts`: mede o número de tentativas de conexão feitas com a instância de banco de dados do Aurora MySQL.
**Variáveis de status globais**
`Aurora_external_connection_count`: mostra o número de conexões de banco de dados com a instância de banco de dados, excluindo as conexões de serviço do RDS usadas para verificações de integridade do banco de dados.
Ao monitorar essas métricas e variáveis de status global, é possível obter visibilidade dos padrões de conexão, dos erros e de possíveis gargalos que possam estar causando problemas de conectividade com sua instância do Amazon Aurora MySQL.
Por exemplo, um número alto de `AbortedClients` ou de `AuroraSlowConnectionHandleCount` pode indicar problemas de conectividade.
Além disso, a configuração de alarmes e de notificações do CloudWatch pode ajudar você a identificar e reagir proativamente aos problemas de conectividade antes que eles aumentem e prejudiquem o desempenho da aplicação.
## Códigos de erro de conectividade do Aurora MySQL e
Veja a seguir alguns erros comuns de conectividade dos bancos de dados do Aurora MySQL e , além de códigos de erro e de explicações.
**Código de erro 1040: muitas conexões**
Este erro ocorre quando o cliente tenta estabelecer mais conexões do que o máximo permitido pelo servidor do banco de dados. As possíveis causas incluem:
+ Configuração incorreta do agrupamento de conexões: se estiver usando um mecanismo de agrupamento de conexões, garanta que o tamanho máximo do grupo não esteja definido como um valor muito alto e que as conexões estejam sendo liberadas adequadamente de volta ao grupo.
+ Configuração da instância do banco de dados: verifique a configuração máxima de conexões permitidas para a instância do banco de dados e ajuste-a, se necessário, definindo o parâmetro `max_connections`.
+ Alta simultaneidade: se vários clientes ou aplicações estiverem se conectando ao banco de dados simultaneamente, o limite máximo permitido de conexões poderá ser atingido.
**Código de erro 1045: acesso negado para o usuário '...'@'...' (usando senha: SIM/NÃO)**
Este erro indica uma falha de autenticação ao tentar se conectar ao banco de dados. As possíveis causas incluem:
+ Compatibilidade do plugin de autenticação: verifique se o plugin de autenticação usado pelo cliente é compatível com o mecanismo de autenticação do servidor de banco de dados.
+ Nome de usuário ou senha incorretos: verifique se o nome de usuário e a senha corretos estão sendo usados na string de conexão ou no mecanismo de autenticação.
+ Permissões do usuário: garanta que o usuário tenha as permissões necessárias para se conectar à instância do banco de dados a partir do host ou da rede especificada.
**Código de erro 1049: banco de dados desconhecido '...'**
Este erro indica que o cliente está tentando se conectar a um banco de dados que não existe no servidor. As possíveis causas incluem:
+ Banco de dados não criado: verifique se o banco de dados especificado foi criado no servidor de banco de dados.
+ Nome incorreto do banco de dados: verifique novamente a precisão do nome do banco de dados usado na string de conexão ou na consulta.
+ Permissões de usuário: verifique se o usuário tem as permissões necessárias para acessar o banco de dados especificado.
**Código de erro 1153: um pacote maior que 'max\$1allowed\$1packet' bytes foi recebido**
Este erro ocorre quando o cliente tenta enviar ou receber dados que excedem o tamanho máximo de pacote permitido pelo servidor do banco de dados. As possíveis causas incluem:
+ Consultas ou conjuntos de resultados grandes: se estiver realizando consultas que envolvam grandes quantidades de dados, o limite de tamanho do pacote pode ser excedido.
+ Configurações de tamanho de pacote mal configuradas: verifique a configuração `max_allowed_packet` no servidor do banco de dados e ajuste-a, se necessário.
+ Problemas de configuração de rede: garanta que a configuração da rede (por exemplo, tamanho da MTU) permita os tamanhos de pacotes necessários.
**Código de erro 1226: o usuário '...' excedeu o recurso 'max\$1user\$1connections' (valor atual: ...)**
Este erro indica que o usuário excedeu o número máximo de conexões simultâneas permitidas pelo servidor de banco de dados. As possíveis causas incluem:
+ Configuração incorreta do agrupamento de conexões: se estiver usando um mecanismo de agrupamento de conexões, garanta que o tamanho máximo do grupo não esteja definido como um valor muito alto para o limite de conexão do usuário.
+ Configuração da instância do banco de dados: verifique a configuração `max_user_connections` da instância do banco de dados e ajuste-a, se necessário.
+ Alta simultaneidade: se vários clientes ou aplicações estiverem se conectando ao banco de dados simultaneamente usando o mesmo usuário, o limite de conexão específico do usuário poderá ser atingido.
**Código de erro 2003: não é possível se conectar ao servidor MySQL em '...' (10061)**
Este erro geralmente ocorre quando o cliente não consegue estabelecer uma conexão TCP/IP com o servidor do banco de dados. Ele pode ser causado por vários motivos, incluindo:
+ Status da instância do banco de dados: verifique se a instância do banco de dados está no estado `available` e não esteja passando por nenhuma operação de manutenção ou backup.
+ Regras de firewall: verifique se algum firewall (do sistema operacional, da rede ou do grupo de segurança) está bloqueando a conexão na porta especificada (geralmente 3306 para MySQL).
+ Nome de host ou endpoint incorreto: verifique se o nome do host ou endpoint usado na cadeia de conexão está correto e corresponde à instância do banco de dados.
+ Problemas de conectividade de rede: verifique se a máquina cliente pode acessar a instância do banco de dados pela rede. Verifique se há interrupções na rede, problemas de roteamento ou configurações incorretas da VPC ou de sub-rede.
**Código de erro 2005: host desconhecido do servidor MySQL '...' (11001)**
Este erro ocorre quando o cliente não consegue enviar o nome do host ou o endpoint do servidor de banco de dados para um endereço IP. As possíveis causas incluem:
+ Problemas de resolução de DNS: verifique se a máquina cliente pode resolver o nome do host corretamente usando o DNS. Verifique as configurações de DNS, o cache DNS e tente usar o endereço IP em vez do nome do host.
+ Nome de host ou endpoint incorreto: verifique novamente a precisão do nome do host ou do endpoint usado na cadeia de conexão.
+ Problemas de configuração de rede: garanta que a configuração de rede do cliente (por exemplo, VPC, sub-rede e tabelas de rotas) permita a resolução de DNS e a conectividade com a instância do banco de dados.
**Código de erro 2026: erro de conexão SSL**
Este erro ocorre quando há um problema com a configuração de SSL/TLS ou com a validação do certificado durante a tentativa de conexão. As possíveis causas incluem:
+ Expiração do certificado: verifique se o certificado SSL/TLS usado pelo servidor expirou e precisa ser renovado.
+ Problemas de validação do certificado: verifique se o cliente é capaz de validar o certificado SSL/TLS do servidor corretamente e se o certificado é confiável.
+ Problemas de configuração de rede: verifique se a configuração de rede permite conexões SSL/TLS e não bloqueia ou interfere no processo de handshake SSL/TLS.
+ Incompatibilidade de configuração SSL/TLS: garanta que as configurações de SSL/TLS (por exemplo, conjuntos de cifras e versões de protocolo) no cliente e no servidor sejam compatíveis.
Ao entender as explicações detalhadas e as possíveis causas de cada código de erro, é possível solucionar melhor os problemas de conectividade ao trabalhar com bancos de dados do Aurora MySQL e .
## Recomendações de ajuste de parâmetros do Aurora MySQL e
**Conexões máximas**
O ajuste desses parâmetros pode ajudar a evitar problemas de conexão causados por atingir o limite máximo permitido de conexões. Esses valores devem ser definidos adequadamente com base nos requisitos de simultaneidade e nas restrições de recursos da sua aplicação.
+ `max_connections`: este parâmetro especifica o número máximo de conexões simultâneas permitidas com a instância de banco de dados.
+ `max_user_connections`: este parâmetro pode ser especificado durante a criação e modificação do usuário e define o número máximo de conexões simultâneas permitidas para uma conta de usuário específica.
**Tamanho do buffer de rede**
Aumentar esses valores pode melhorar o desempenho da rede, especialmente para workloads que envolvem grandes transferências de dados ou conjuntos de resultados. No entanto, é preciso ter cuidado, pois tamanhos maiores de buffer podem consumir mais memória.
+ `net_buffer_length`: este parâmetro define o tamanho inicial da conexão do cliente e dos buffers de resultados, equilibrando o uso da memória com o desempenho da consulta.
+ `max_allowed_packet`: este parâmetro especifica o tamanho máximo de um único pacote de rede que pode ser enviado ou recebido pela instância de banco de dados.
**Compressão de rede (lado do cliente)**
Habilitar a compressão de rede pode reduzir o uso da largura de banda da rede, mas pode aumentar a sobrecarga da CPU nos lados do cliente e do servidor.
+ `compress`: este parâmetro habilita ou desabilita a compressão de rede para a comunicação cliente/servidor.
+ `compress_protocol`: este parâmetro especifica o protocolo de compressão a ser usado para comunicação de rede.
**Ajuste de desempenho da rede**
Ajustar esses tempos limite pode auxiliar a gerenciar conexões ociosas e evitar o esgotamento de recursos. No entanto, é preciso ter cuidado, pois valores baixos podem causar encerramentos prematuros de conexão.
+ `interactive_timeout`: este parâmetro especifica o número de segundos que o servidor espera por atividade em uma conexão interativa antes de fechá-la.
+ `wait_timeout`: este parâmetro determina o número de segundos que o servidor espera por atividade em uma conexão não interativa antes de fechá-la.
**Configurações de tempo limite de rede**
Ajustar esses tempos limite pode ajudar a resolver problemas relacionados a conexões lentas ou sem resposta. No entanto, tenha cuidado para não definir valores muito baixos, pois isso pode causar falhas de conexão prematuras.
+ `net_read_timeout`: este parâmetro especifica o número de segundos de espera por mais dados de uma conexão antes de encerrar a operação de leitura.
+ `net_write_timeout`: este parâmetro determina o número de segundos de espera para que um bloco seja gravado em uma conexão antes de encerrar a operação de gravação.
## Exemplos de solução de problemas de conexão de banco de dados do Aurora MySQL e
Os exemplos a seguir mostram como identificar e solucionar problemas de conexão de banco de dados do Aurora MySQL e .
### Exemplo 1: solução de problemas em tentativas de conexão malsucedidas
As tentativas de conexão podem falhar por vários motivos, incluindo falhas de autenticação, falhas de handshake SSL/TLS, `max_connections` com limite atingido e restrições de recursos na instância de banco de dados.
É possível rastrear o número de conexões com falha com o Insights de Performance ou usando o comando a seguir.
```
mysql> show global status like 'aborted_connects';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Aborted_connects | 7 |
+------------------+-------+
1 row in set (0.00 sec)
```
Se o número de `Aborted_connects` aumentar com o tempo, a aplicação pode estar tendo problemas intermitentes de conectividade.
Você pode usar a [Auditoria avançada do Aurora](AuroraMySQL.Auditing.md) para registrar as conexões e desconexões das conexões do cliente. Você pode fazer isso definindo os seguintes parâmetros no grupo de parâmetros do cluster de banco de dados:
+ `server_audit_logging` = `1`
+ `server_audit_events` = `CONNECT`
Veja a seguir um extrato dos logs de auditoria de uma falha de login.
```
1728498527380921,auora-mysql-node1,user_1,172.31.49.222,147189,0,FAILED_CONNECT,,,1045
1728498527380940,auora-mysql-node1,user_1,172.31.49.222,147189,0,DISCONNECT,,,0
```
Em que:
+ `1728498527380921`: o carimbo de data/hora da época em que ocorreu falha no login
+ `aurora-mysql-node1`: o identificador da instância do nó do cluster do Aurora MySQL no qual houve falha de conexão
+ `user_1`: o nome do usuário do banco de dados para o qual houve falha de login
+ `172.31.49.222`: o endereço IP privado do cliente pelo qual a conexão foi estabelecida
+ `147189`: o ID de conexão do login com falha
+ `FAILED_CONNECT`: indica que a conexão falhou.
+ `1045`: o código de retorno. Um valor diferente de zero indica um erro. Nesse caso, `1045` corresponde ao acesso negado.
Para obter mais informações, consulte [Server error codes](https://dev.mysql.com/doc/mysql-errors/5.7/en/server-error-reference.html) e [Client error codes](https://dev.mysql.com/doc/mysql-errors/5.7/en/client-error-reference.html) na documentação do MySQL.
Você também pode examinar os logs de erro do Aurora MySQL em busca de quaisquer mensagens de erro relacionadas, por exemplo:
```
2024-10-09T19:26:59.310443Z 220 [Note] [MY-010926] [Server] Access denied for user 'user_1'@'172.31.49.222' (using password: YES) (sql_authentication.cc:1502)
```
### Exemplo 2: solução de problemas de desconexões anormais do cliente
É possível rastrear o número de desconexões anormais de clientes com o Insights de Performance ou usando o comando a seguir.
```
mysql> show global status like 'aborted_clients';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Aborted_clients | 9 |
+-----------------+-------+
1 row in set (0.01 sec)
```
Se o número de `Aborted_clients` aumentar ao longo do tempo, a aplicação não está fechando as conexões com o banco de dados corretamente. Se as conexões não forem fechadas adequadamente, isso pode levar a vazamentos de recursos e possíveis problemas de desempenho. Conexões abertas desnecessariamente podem consumir recursos do sistema, como memória e descritores de arquivos, o que pode eventualmente fazer com que a aplicação ou o servidor pare de responder ou reinicie.
Você pode usar a consulta a seguir para identificar contas que não estão fechando conexões corretamente. Ela recupera o nome da conta do usuário, o host do qual o usuário está se conectando, o número de conexões abertas e a porcentagem de conexões não fechadas.
```
SELECT
ess.user,
ess.host,
(a.total_connections - a.current_connections) - ess.count_star AS not_closed,
(((a.total_connections - a.current_connections) - ess.count_star) * 100) / (a.total_connections - a.current_connections) AS pct_not_closed
FROM
performance_schema.events_statements_summary_by_account_by_event_name AS ess
JOIN performance_schema.accounts AS a ON (ess.user = a.user AND ess.host = a.host)
WHERE
ess.event_name = 'statement/com/quit'
AND (a.total_connections - a.current_connections) > ess.count_star;
+----------+---------------+------------+----------------+
| user | host | not_closed | pct_not_closed |
+----------+---------------+------------+----------------+
| user1 | 172.31.49.222 | 1 | 33.3333 |
| user1 | 172.31.93.250 | 1024 | 12.1021 |
| user2 | 172.31.93.250 | 10 | 12.8551 |
+----------+---------------+------------+----------------+
3 rows in set (0.00 sec)
```
Depois de identificar as contas de usuário e os hosts dos quais as conexões não estão sendo fechadas, é possível verificar o código que não está fechando as conexões adequadamente.
Por exemplo, com o conector MySQL em Python, use o método `close()` do objeto de conexão para fechar conexões. Veja a seguir um exemplo de função que estabelece uma conexão com um banco de dados, executa uma consulta e fecha a conexão:
```
import mysql.connector
def execute_query(query):
# Establish a connection to the database
connection = mysql.connector.connect(
host="your_host",
user="your_username",
password="your_password",
database="your_database"
)
try:
# Create a cursor object
cursor = connection.cursor()
# Execute the query
cursor.execute(query)
# Fetch and process the results
results = cursor.fetchall()
for row in results:
print(row)
finally:
# Close the cursor and connection
cursor.close()
connection.close()
```
Neste exemplo, o método `connection.close()` é chamado no bloco `finally` para garantir que a conexão seja fechada, independentemente de ocorrer ou não uma exceção.
### Exemplo 3: solução de problemas em tentativas de conexão malsucedidas do IAM
A conectividade com os usuários do AWS Identity and Access Management (IAM) pode falhar por vários motivos, como:
+ Configuração incorreta da política do IAM
+ Credenciais de segurança expiradas
+ Problemas de conectividade de rede
+ Incompatibilidade de permissões de banco de dados
Para solucionar esses erros de autenticação, habilite o recurso de exportação de logs `iam-db-auth-error` em seu Amazon Relational Database Service (RDS) ou banco de dados Aurora. Isso permitirá que você visualize mensagens de erro de autenticação detalhadas no grupo de logs do CloudWatch para seu cluster do Amazon RDS ou do Amazon Aurora.
Depois de habilitados, você pode revisar esses logs para identificar e resolver a causa específica das falhas de autenticação do IAM.
Por exemplo:
```
2025-09-22T12:02:30,806 [ERROR] Failed to authorize the connection request for user 'user_1' due to an internal IAM DB Auth error. (Status Code: 500, Error Code: InternalError)
```
e
```
2025-09-22T12:02:51,954 [ERROR] Failed to authenticate the connection request for user 'user_2' because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)
```
Para receber orientação sobre solução de problemas, consulte o guia de solução de problemas do [Aurora](UsingWithRDS.IAMDBAuth.Troubleshooting.md) para autenticação de banco de dados do IAM.
# Solucionar problemas de performance em bancos de dados do Aurora MySQL
O MySQL fornece [controle do otimizador de consultas](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html) por meio de variáveis do sistema que afetam a forma como os planos de consulta são avaliados, otimizações selecionáveis, dicas de otimizador e índice e o modelo de custo do otimizador. Esses pontos de dados podem ser úteis não apenas para comparar diferentes ambientes do MySQL, mas também para comparar planos de execução de consultas anteriores com planos de execução atuais e para entender a execução geral de uma consulta do MySQL a qualquer momento.
O desempenho da consulta depende de muitos fatores, incluindo o plano de execução, o esquema e o tamanho da tabela, estatísticas, recursos, índices e configuração de parâmetros. O ajuste de consultas requer a identificação de gargalos e a otimização do caminho de execução.
+ Encontre o plano de execução da consulta e verifique se ela está usando índices apropriados. É possível otimizar a consulta usando `EXPLAIN` e revisando os detalhes de cada plano.
+ O Aurora MySQL versão 3 (compatível com o MySQL 8.0 Community Edition) usa uma instrução `EXPLAIN ANALYZE`. A instrução `EXPLAIN ANALYZE` é uma ferramenta de criação de perfil que mostra onde o MySQL gasta tempo na consulta e por quê. Com `EXPLAIN ANALYZE`, o Aurora MySQL planeja, prepara e executa a consulta enquanto conta as linhas e mede o tempo gasto em vários pontos do plano de execução. Quando a consulta é concluída, `EXPLAIN ANALYZE` imprime o plano e suas medições em vez do resultado da consulta.
+ Mantenha as estatísticas do esquema atualizadas usando a instrução `ANALYZE`. Às vezes, o otimizador de consultas pode escolher planos de execução inadequados devido a estatísticas desatualizadas. Isso pode levar a um desempenho insatisfatório de uma consulta devido às estimativas de cardinalidade imprecisas das tabelas e dos índices. A coluna `last_update` da tabela [innodb\$1table\$1stats](https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html#innodb-persistent-stats-tables) mostra a última vez que as estatísticas do esquema foram atualizadas, o que é um bom indicador de “desatualização”.
+ Outros problemas podem ocorrer, como distorção da distribuição de dados, que não são levados em consideração para a cardinalidade da tabela. Consulte mais informações em [Estimating ANALYZE TABLE complexity for InnoDB tables](https://dev.mysql.com/doc/refman/8.0/en/innodb-analyze-table-complexity.html) e [Histogram statistics in MySQL](https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/) na documentação do MySQL.
## Noções básicas do tempo gasto com consultas
Veja a seguir formas de determinar o tempo gasto pelas consultas:
+ [Criação de perfil](https://dev.mysql.com/doc/refman/8.0/en/show-profile.html)
+ [Esquema de desempenho](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)
+ [Otimizador de consultas](https://dev.mysql.com/doc/refman/8.0/en/controlling-optimizer.html)
**Criação de perfil**
Por padrão, a criação de perfil está desabilitada. Habilite a criação de perfil, depois execute a consulta lenta e revise seu perfil.
```
SET profiling = 1;
Run your query.
SHOW PROFILE;
```
1. Identifique o estágio em que a maior parte do tempo é gasto. De acordo com [General thread states](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html) na documentação do MySQL, ler e processar linhas de uma instrução `SELECT` geralmente é o estado de execução mais longa durante a vida útil de uma determinada consulta. É possível usar a instrução `EXPLAIN` para entender como o MySQL executa essa consulta.
1. Analise o log de consultas lentas para avaliar `rows_examined` e `rows_sent` a fim de garantir que a workload seja semelhante em cada ambiente. Para obter mais informações, consulte [Registro em log de bancos de dados do Aurora MySQL](aurora-mysql-troubleshooting-logging.md).
1. Execute o comando a seguir para tabelas que fazem parte da consulta identificada:
```
SHOW TABLE STATUS\G;
```
1. Capture as seguintes saídas antes e depois de executar a consulta em cada ambiente:
```
SHOW GLOBAL STATUS;
```
1. Execute os comandos a seguir em cada ambiente para ver se há alguma outra consulta/sessão influenciando o desempenho dessa consulta de amostra.
```
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G;
```
Às vezes, quando os recursos no servidor estão ocupados, isso afeta todas as outras operações no servidor, incluindo consultas. Também é possível capturar informações periodicamente quando as consultas são executadas ou configurar um trabalho `cron` para capturar informações em intervalos úteis.
**Performance Schema**
O Performance Schema fornece informações úteis sobre o desempenho do tempo de execução do servidor, embora tenha um impacto mínimo sobre esse desempenho. Isso é diferente de `information_schema`, que fornece informações de esquema sobre a instância de banco de dados. Para obter mais informações, consulte [Visão geral do Performance Schema para o Insights de Performance no Aurora MySQL](USER_PerfInsights.EnableMySQL.md).
**Rastreamento do otimizador de consulta**
Para entender por que um [plano de consulta específico foi escolhido para execução](https://dev.mysql.com/doc/refman/8.0/en/execution-plan-information.html), é possível configurar `optimizer_trace` para acessar o otimizador de consultas do MySQL.
Execute um rastreamento do otimizador para mostrar informações abrangentes sobre todos os caminhos disponíveis para o otimizador e sua escolha.
```
SET SESSION OPTIMIZER_TRACE="enabled=on";
SET optimizer_trace_offset=-5, optimizer_trace_limit=5;
-- Run your query.
SELECT * FROM table WHERE x = 1 AND y = 'A';
-- After the query completes:
SELECT * FROM information_schema.OPTIMIZER_TRACE;
SET SESSION OPTIMIZER_TRACE="enabled=off";
```
## Revisar as configurações do otimizador de consultas
O Aurora MySQL versão 3 (compatível com MySQL 8.0 Community Edition) tem muitas alterações relacionadas ao otimizador em comparação com o Aurora MySQL versão 2 (compatível com o MySQL 5.7 Community Edition). Se você tiver alguns valores personalizados para `optimizer_switch`, recomendamos que analise as diferenças nos padrões e defina os valores de `optimizer_switch` que funcionem melhor para sua workload. Também recomendamos que você teste as opções disponíveis para o Aurora MySQL versão 3 para examinar o desempenho das consultas.
**nota**
O Aurora MySQL versão 3 usa o valor padrão da comunidade de 20 para o parâmetro [innodb\$1stats\$1persistent\$1sample\$1pages](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_stats_persistent_sample_pages).
É possível usar o seguinte comando para mostrar os valores de `optimizer_switch`:
```
SELECT @@optimizer_switch\G;
```
A tabela a seguir mostra os valores padrão de `optimizer_switch` do Aurora MySQL versões 2 e 3.
| Configuração | Aurora MySQL versão 2 | Aurora MySQL versão 3 |
| --- | --- | --- |
| batched\$1key\$1access | desligar | desligar |
| block\$1nested\$1loop | ativado | ativado |
| condition\$1fanout\$1filter | ativado | ativado |
| derived\$1condition\$1pushdown | – | ativado |
| derived\$1merge | ativado | ativado |
| duplicateweedout | ativado | ativado |
| engine\$1condition\$1pushdown | ativado | ativado |
| firstmatch | ativado | ativado |
| hash\$1join | desligar | ativado |
| hash\$1join\$1cost\$1based | ativado | – |
| hypergraph\$1optimizer | – | desligar |
| index\$1condition\$1pushdown | ativado | ativado |
| index\$1merge | ativado | ativado |
| index\$1merge\$1intersection | ativado | ativado |
| index\$1merge\$1sort\$1union | ativado | ativado |
| index\$1merge\$1union | ativado | ativado |
| loosescan | ativado | ativado |
| materialization | ativado | ativado |
| mrr | ativado | ativado |
| mrr\$1cost\$1based | ativado | ativado |
| prefer\$1ordering\$1index | ativado | ativado |
| semijoin | ativado | ativado |
| skip\$1scan | – | ativado |
| subquery\$1materialization\$1cost\$1based | ativado | ativado |
| subquery\$1to\$1derived | – | desligar |
| use\$1index\$1extensions | ativado | ativado |
| use\$1invisible\$1indexes | – | desligar |
Consulte mais informações em [Switchable optimizations (MySQL 5.7)](https://dev.mysql.com/doc/refman/5.7/en/switchable-optimizations.html) e [Switchable optimizations (MySQL 8.0)](https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html) na documentação do MySQL.