# Ajustar o Aurora MySQL com insights proativos do Amazon DevOps Guru Os insights proativos do DevOps Guru detectam condições problemáticas conhecidas em clusters de banco de dados do Aurora MySQL antes que elas ocorram. O DevOps Guru pode fazer o seguinte: + Evitar muitos problemas comuns de bancos de dados ao comparar a configuração do seu banco de dados com as configurações comuns recomendadas. + Alertar sobre problemas críticos em sua frota que, se não forem controlados, poderão causar problemas maiores no futuro. + Alertar sobre problemas recém-descobertos. Cada insight proativo contém uma análise da causa do problema e recomendações de ações corretivas. **Topics** + [O tamanho da lista de histórico do InnoDB aumentou significativamente](proactive-insights.history-list.md) + [O banco de dados está criando tabelas temporárias no disco](proactive-insights.temp-tables.md) # O tamanho da lista de histórico do InnoDB aumentou significativamente A lista de histórico de alterações de linha aumentou significativamente desde *data* até *tamanho* em *db-instance*. Esse aumento afeta a performance de consulta e do desligamento do banco de dados. **Topics** + [Versões compatíveis do mecanismo](#proactive-insights.history-list.context.supported) + [Contexto](#proactive-insights.history-list.context) + [Causas prováveis desse problema](#proactive-insights.history-list.causes) + [Ações](#proactive-insights.history-list.actions) + [Métricas relevantes](#proactive-insights.history-list.metrics) ## Versões compatíveis do mecanismo Essas informações de insights são compatíveis com todas as versões do Aurora MySQL. ## Contexto O sistema de transações do InnoDB mantém o controle de simultaneidade de várias versões (MVCC). Quando uma linha é modificada, a versão pré-modificação dos dados que estão sendo modificados é armazenada como um registro de anulação em um log de anulação. Cada registro de anulação tem uma referência ao seu registro de redefinição anterior, formando uma lista vinculada. A lista de histórico do InnoDB é uma lista global dos registros de anulação de transações confirmadas. O MySQL usa a lista de histórico para remover os registros e as páginas de log quando as transações não precisarem mais do histórico. O tamanho da lista de histórico é o número total de registros de anulação que contêm modificações na lista do histórico. Cada log contém uma ou mais modificações. Se a lista de histórico do InnoDB ficar muito grande, indicando um grande número de versões de linhas antigas, as consultas e os desligamentos de bancos de dados ficarão mais lentos. ## Causas prováveis desse problema As causas comuns para uma longa lista de histórico incluem o seguinte: + Transações de longa duração, seja de leitura ou gravação + Uma carga de gravação pesada ## Ações Recomendamos ações distintas dependendo dos motivos do insight. **Topics** + [Não inicie nenhuma operação que envolve um desligamento de banco de dados até que a lista de histórico do InnoDB diminua](#proactive-insights.history-list.actions.no-shutdown) + [Identificar e encerrar transações de longa duração](#proactive-insights.history-list.actions.long-txn) + [Identificar os principais hosts e usuários usando o recurso Insights de Performance](#proactive-insights.history-list.actions.top-PI) ### Não inicie nenhuma operação que envolve um desligamento de banco de dados até que a lista de histórico do InnoDB diminua Como uma lista de histórico do InnoDB longa retarda desligamentos de banco de dados, reduza o tamanho da lista antes de iniciar operações que envolvam o desligamento de um banco de dados. Essas operações incluem upgrades da versão primária de bancos de dados. ### Identificar e encerrar transações de longa duração Você pode encontrar transações de longa duração consultando `information_schema.innodb_trx`. **nota** Certifique-se também de procurar transações de longa duração em réplicas de leitura. **Como identificar e encerrar transações de longa duração** 1. No cliente SQL, execute a seguinte consulta: ``` SELECT a.trx_id, a.trx_state, a.trx_started, TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open", a.trx_rows_modified, b.USER, b.host, b.db, b.command, b.time, b.state FROM information_schema.innodb_trx a, information_schema.processlist b WHERE a.trx_mysql_thread_id=b.id AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10 ORDER BY trx_started ``` 1. Encerre cada transação de longa duração com o procedimento armazenado [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill). ### Identificar os principais hosts e usuários usando o recurso Insights de Performance Otimize as transações para que grandes quantidades de linhas modificadas sejam imediatamente confirmadas. ## Métricas relevantes As métricas a seguir estão relacionadas a esse insight: + `trx_rseg_history_len`: essa métrica do contador pode ser visualizada no Insights de Performance, bem como na tabela `INFORMATION_SCHEMA.INNODB_METRICS`. Para obter mais informações, consulte a [Tabela de métricas INFORMATION\$1SCHEMA do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html) na documentação do MySQL. + `RollbackSegmentHistoryListLength`: essa métrica do Amazon CloudWatch mede os logs de ações desfeitas que registram transações confirmadas com registros marcados para exclusão. Esses registros estão programados para serem processados pela operação de limpeza do InnoDB. A métrica `trx_rseg_history_len` tem o mesmo valor que `RollbackSegmentHistoryListLength`. + `PurgeBoundary`: o número da transação até o qual a limpeza do InnoDB é permitida. Se essa métrica do CloudWatch não avançar por longos períodos, é uma boa indicação de que a limpeza do InnoDB está bloqueada por transações de longa duração. Para investigar, confira as transações ativas no cluster de banco de dados do Aurora MySQL. Essa métrica está disponível apenas para o Aurora MySQL versão 2.11 e posteriores e versões 3.08 e posteriores. + `PurgeFinishedPoint`: o número da transação até o qual a limpeza do InnoDB é realizada. Essa métrica do CloudWatch pode ajudar a examinar a rapidez com que a limpeza do InnoDB está progredindo. Essa métrica está disponível apenas para o Aurora MySQL versão 2.11 e posteriores e versões 3.08 e posteriores. + `TransactionAgeMaximum`: a idade da transação em execução ativa mais antiga. Essa métrica do CloudWatch está disponível para o Aurora MySQL versão 3.08 e posteriores. + `TruncateFinishedPoint`: o número da transação até o qual o truncamento é desfeito. Essa métrica do CloudWatch está disponível apenas para o Aurora MySQL versão 2.11 e posteriores e versões 3.08 e posteriores. Para obter mais informações sobre as 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 banco de dados está criando tabelas temporárias no disco Seu uso recente de tabelas temporárias em disco aumentou significativamente, até *porcentagem*. O banco de dados está criando cerca de *número* tabelas temporárias por segundo. Isso pode afetar a performance e aumentar as operações no disco em *instância de banco de dados*. **Topics** + [Versões compatíveis do mecanismo](#proactive-insights.temp-tables.context.supported) + [Contexto](#proactive-insights.temp-tables.context) + [Causas prováveis desse problema](#proactive-insights.temp-tables.causes) + [Ações](#proactive-insights.temp-tables.actions) + [Métricas relevantes](#proactive-insights.temp-tables.metrics) ## Versões compatíveis do mecanismo Essas informações de insights são compatíveis com todas as versões do Aurora MySQL. ## Contexto Às vezes, o servidor MySQL precisa criar uma tabela temporária interna ao processar uma consulta. O Aurora MySQL pode conter uma tabela temporária interna na memória, onde ela pode ser processada pelo mecanismo de armazenamento TempTable ou MEMORY, ou armazenada em disco pelo InnoDB. Para obter mais informações, consulte [Uso de tabela temporária interna no MySQL](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html) no *Manual de referência do MySQL*. ## Causas prováveis desse problema Um aumento nas tabelas temporárias em disco indica o uso de consultas complexas. Se a memória configurada for insuficiente para armazenar tabelas temporárias na memória, o Aurora MySQL criará as tabelas no disco. Isso pode afetar a performance e aumentar as operações no disco. ## Ações Recomendamos ações distintas dependendo dos motivos do insight. + Para o Aurora MySQL versão 3, recomendamos que você use o mecanismo de armazenamento TempTable. + Otimize suas consultas para retornar menos dados selecionando somente as colunas necessárias. Se você ativar o esquema de performance com todos os instrumentos `statement` habilitados e cronometrados, poderá consultar `SYS.statements_with_temp_tables` para recuperar a lista de consultas que usam tabelas temporárias. Para obter mais informações, consulte [Pré-requisitos para usar o esquema sys](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html) na documentação do MySQL. + Considere indexar colunas envolvidas em operações de classificação e agrupamento. + Reescreva suas consultas para evitar as colunas `BLOB` e `TEXT`. Essas colunas sempre usam o disco. + Ajuste os seguintes parâmetros de banco de dados: `tmp_table_size` e `max_heap_table_size`. O valor padrão para esses parâmetros é 16 MiB. Ao usar o mecanismo de armazenamento MEMORY para tabelas temporárias na memória, o tamanho máximo delas é definido pelo valor `tmp_table_size` ou `max_heap_table_size`, o que for menor. Quando esse tamanho máximo é atingido, o MySQL converte automaticamente a tabela temporária interna na memória em uma tabela temporária interna em disco do InnoDB. Para obter mais informações, consulte [Usar o mecanismo de armazenamento TempTable no Amazon RDS para MySQL e Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/). **nota** Ao criar explicitamente tabelas MEMORY com CREATE TABLE, somente a variável `max_heap_table_size` determina o tamanho máximo até o qual uma tabela pode crescer. Também não há conversão para um formato em disco. ## Métricas relevantes As seguintes métricas do recurso Insights de Performance estão relacionadas a esse insight: + Created\$1tmp\$1disk\$1tables + Created\$1tmp\$1tables Para obter mais informações, consulte [Created\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables) na documentação do MySQL.