ApsaraDB RDS:FAQ about the general query log feature of ApsaraDB RDS for MySQL

Por que o RDS armazena logs gerais de consultas em uma tabela?

Por padrão, o ApsaraDB RDS for MySQL armazena logs gerais de consultas em uma tabela de banco de dados em vez de um arquivo por dois motivos:

• Usuários não têm acesso direto aos arquivos da instância RDS; portanto, não é possível consultar ou baixar logs baseados em arquivos.

• O parâmetro log_output controla o formato de saída dos logs gerais de consultas e dos logs de consultas lentas. Como o RDS faz rotação dos logs de consultas lentas e exige seu armazenamento em tabelas, os logs gerais de consultas também devem ser armazenados em tabelas.

Por que o log geral de consultas esgota o armazenamento?

Cada instrução SQL executada na instância gera uma entrada de log. Quando o log geral de consultas permanece ativado por muito tempo ou a instância processa alto volume de consultas, a tabela mysql.general_log cresce continuamente. Sem limpeza periódica, essa tabela preenche todo o armazenamento da instância.

Para confirmar se o log geral de consultas causa o problema de armazenamento:

1. Verifique o uso de armazenamento na página de monitoramento da instância. Se sys_data_size estiver anormalmente grande, os dados da tabela consomem armazenamento. Para mais detalhes, consulte Visualize the monitoring information.

2. Consulte Visualize the instance parameters. Se general_log estiver definido como ON, o recurso está ativo.

Por que o log geral de consultas causa problemas de desempenho?

Com o log geral de consultas ativado, cada thread que executa uma instrução SQL precisa gravar uma linha na tabela mysql.general_log. Essa operação exige locks de metadados (MDLs) e locks de tabela, o que força as threads a gravarem sequencialmente, e não em paralelo.

Sob alto volume de conexões, muitas threads competem simultaneamente por esses locks, deixando as conexões no estado Waiting for table level lock. À medida que o número de conexões aumenta, a utilização da CPU também sobe.

Para confirmar, execute SHOW PROCESSLIST ou consulte a tabela innodb_trx. Se muitas conexões exibirem Waiting for table level lock, o log geral de consultas contribui para a contenção de locks.

Por que o log geral de consultas aumenta o tempo de recuperação?

Se uma instância RDS for desligada inesperadamente, o marcador de falha do log geral de consultas será definido como true. Ao reiniciar, a instância inicia um processo automático de recuperação. Caso as tabelas da instância RDS tenham tamanho elevado, a restauração demora bastante, período em que a instância permanece indisponível. Isso estende diretamente o objetivo de tempo de recuperação (RTO).

Solução

1. Defina general_log como OFF para interromper a gravação de novas entradas de log. Consulte Modifique instance parameters.

2. Conecte-se à instância com uma conta privilegiada. Consulte Connect to an ApsaraDB RDS for MySQL instance.

3. Limpe a tabela de log:

   A instrução TRUNCATE não tem suporte em instâncias com MySQL 5.6. Nessas instâncias, entre em contato com o technical support para limpar o log. Para obter a lista completa de suporte a recursos por versão, consulte Features . Para executar a instrução TRUNCATE com uma conta privilegiada , a instância deve executar uma versão secundária do mecanismo compatível: 20210630 ou posterior para ApsaraDB RDS for MySQL 5.7 e 20210930 ou posterior para ApsaraDB RDS for MySQL 8.0. Em instâncias com versões secundárias anteriores do mecanismo, a instrução TRUNCATE falha mesmo com uma conta privilegiada . Nesse caso, envie um ticket para que o suporte técnico limpe o log.

   TRUNCATE TABLE mysql.general_log;

Após limpar o log, verifique a página de monitoramento da instância para confirmar a redução do uso de armazenamento.

Alternativas para análise de SQL

Mantenha o log geral de consultas desativado durante operações normais. Ative-o apenas para sessões curtas de depuração e, em seguida, desative-o e limpe a tabela imediatamente após o uso.

Para análise contínua de SQL, utilize uma das seguintes abordagens:

• SQL Explorer and Audit (recomendado): Ative este recurso para registrar e analisar automaticamente as instruções SQL. Os dados ficam armazenados no Database Autonomy Service (DAS) e não consomem o armazenamento da instância RDS, sem impacto no desempenho. Consulte Use the SQL Explorer and Audit feature.

• Log geral de consultas temporário: Caso precise depurar um problema específico, ative o log geral de consultas e consulte a tabela de log para inspecionar a atividade SQL:

  SELECT * FROM mysql.general_log;

  Desative o recurso e limpe a tabela assim que concluir a depuração.

O que fazer se o armazenamento já estiver esgotado

Se a instância ficar sem armazenamento antes da limpeza do log, expanda a capacidade de armazenamento:

• Expansão manual: Altere as especificações da instância para aumentar o armazenamento. Consulte Change instance specifications.

• Expansão automática: Configure a expansão automática de armazenamento para que o sistema aumente a capacidade quando o uso atingir um limiar especificado. Consulte Configure automatic storage expansion.