Como solucionar alta utilização de CPU e o desempenho lento da consulta depois de fazer upgrade da minha instância de banco de dados Amazon RDS para MySQL ou Aurora compatível com MySQL?

Resolução

Pré-requisitos:

Para evitar problemas de diagnóstico incorreto, estruture corretamente seu fluxo de trabalho de solução de problemas e use as ferramentas e os serviços da AWS. Para obter mais informações, consulte os seguintes artigos:

• Como soluciono problemas e resolvo a alta utilização da CPU em uma instância de banco de dados do Amazon RDS para MySQL ou do Amazon Aurora MySQL?
• Como soluciono problemas de consulta lenta e melhoro seu desempenho no Amazon RDS para MySQL?

Verifique se há problemas específicos de upgrade

Quando você faz upgrade em uma instância, como o Aurora 5.7 compatível com MySQL para o 8.0 compatível com o MySQL, o upgrade pode remover certos atributos da instância.

Se sua instância usa atributos descontinuados, é possível ter problemas com o desempenho da sua instância. Para verificar se a versão da sua instância usa atributos descontinuados que afetam seu workload, consulte Notas de lançamento para o Amazon Aurora edição compatível com MySQL. Ou consulte MySQL 8.0 Release notes (Notas de lançamento do MySQL 8.0) no site do MySQL.

No exemplo de cenário a seguir, você faz upgrade um cluster 5.7 do Aurora compatível com MySQL para o 8.0. Após o upgrade, a CPU da instância de gravação dobra, mesmo que as consultas, planos de execução e padrões workload sejam os mesmos.

Para solucionar esse problema, é possível analisar as métricas do seu cluster do Amazon RDS para MySQL ou do Aurora compatível com MySQL. Com base no problema, compare as métricas relacionadas ao cluster da versão anterior com a versão com upgrade.

Exemplo de métricas do Aurora compatível com o MySQL 5.7:

SHOW GLOBAL STATUS LIKE 'Qcache%';

Exemplo de métricas do Aurora compatível com o MySQL 8.0:

`mysql> SHOW STATUS LIKE 'Qcache%';`  
`+-------------------------+--------+`  
`| Variable_name | Value |`  
`+-------------------------+--------+`  
`| Qcache_free_blocks | 36 |`  
`| Qcache_free_memory | 138488 |`  
`| Qcache_hits | 79570 |`  
`| Qcache_inserts | 27087 |`  
`| Qcache_lowmem_prunes | 3114 |`  
`| Qcache_not_cached | 22989 |`  
`| Qcache_queries_in_cache | 415 |`  
`| Qcache_total_blocks | 912 |`  
`+-------------------------+--------+`

Neste exemplo, o Aurora compatível com MySQL 8.0, removeu um atributo que atendia consultas do cache para evitar execuções completas. Sem esse atributo, o Aurora MySQL executa totalmente todas as consultas e dobra o workload.

Se você observar picos na CPU da instância, analise as seguintes métricas:

• Consultas
• Com_select
• Innodb_rows_read

Para solucionar problemas com essas métricas, conclua as seguintes tarefas:

• Escale verticalmente para lidar com a carga imediata da CPU.
• Use instruções preparadas. Para mais informações, consulte Instruções preparadas no site do MySQL.
• Use o Amazon ElastiCache para armazenar suas configurações de cluster em cache.

Outras etapas de solução de problemas

É possível comparar a versão anterior dos planos de execução com os planos de execução da versão com upgrade para solucionar melhor os problemas. Para comparar as configurações do grupo de parâmetros, use a consulta EXPLAIN FORMAT=JSON. Configurações críticas, como innodb_buffer_pool_size devem ser as mesmas nas duas versões. Para obter mais informações, consulte Configuring InnoDB Buffer Pool Size (Configurando o tamanho do pool de buffer do InnoDB) e declaração EXPLAIN no site do MySQL.

É uma prática recomendada usar o atributo de clonagem do Aurora para testar upgrades em um ambiente de preparação. É possível usar ferramentas como o Sysbench para simular workloads no ambiente de preparação. Em seguida, use as ferramentas da AWS, como o AWS Database Insights e o Monitoramento aprimorado, para monitorar as principais métricas.