Quando uma instância do ApsaraDB RDS for MySQL fica sem armazenamento, ela é bloqueada automaticamente no modo de somente leitura para evitar a perda de dados. Este tópico explica como identificar qual tipo de arquivo está consumindo espaço e como resolver cada causa.
Resposta de emergência
Se a instância já estiver bloqueada (somente leitura), expanda o disco imediatamente para restaurar o acesso de gravação. Execute todas as limpezas e correções da causa raiz após a restauração do service.
No console do RDS, clique no ID da instância.
Manually resize the disk para desbloquear a instância.
O sistema desbloqueia a instância em aproximadamente 5 minutos após a conclusão do redimensionamento. Você pode acompanhar o progresso na Central de Tarefas.
Redimensionar o disco é uma solução alternativa de curto prazo. O armazenamento será preenchido novamente, a menos que você também resolva a causa raiz abaixo.
Visualizar o uso de armazenamento
O espaço de armazenamento de uma instância do RDS for MySQL inclui dados do usuário, dados do sistema, logs e arquivos temporários.
No console do RDS, clique no ID da instância.
No painel de navegação à esquerda, escolha Monitoring and Alerts > Standard Monitoring.
Encontre a visualização MySQL Storage Space Used. Clique no ícone ao lado do título da visualização para ver a descrição de cada parâmetro.
Para obter etapas detalhadas de monitoramento, consulte Visualizar as informações de monitoramento.
Identificar a causa
Verifique a visualização MySQL Storage Space Used e correlacione o parâmetro de alto uso com o tipo de arquivo e a solução abaixo.
|
Tipo de arquivo |
Parâmetro no Monitoramento Padrão |
Parâmetro na Análise de Espaço |
Solução |
|
Arquivo temporário |
|
|
|
|
Arquivo de binlog |
|
|
|
|
Arquivo de undo log |
|
|
|
|
Arquivo de general log |
|
|
|
|
Arquivo de dados do usuário |
|
|
Verifique também a fragmentação e o inchaço de índices, que não aparecem como parâmetros separados, mas podem consumir um espaço significativo:
Fragmentação: consulte Fragmentation accumulation
Inchaço de índice: consulte Acúmulo de arquivos de índice
Acúmulo de arquivos temporários
Arquivos temporários são criados quando o MySQL executa instruções SQL que classificam, agrupam ou unem grandes conjuntos de dados. Logs binários para grandes transações também são armazenados em cache temporariamente até que a transação seja confirmada. Se esses arquivos se acumularem, a instância será bloqueada.
Resolva o bloqueio imediato:
MySQL 5.7 ou anterior: Restart the instance. O sistema exclui arquivos temporários automaticamente na reinicialização.
MySQL 8.0: A instância encerra todas as sessões de usuário e inicia uma reversão automática. Os arquivos temporários são liberados após a conclusão da reversão.
Se a instância não for desbloqueada automaticamente, execute show processlist para identificar sessões com status de Copy to tmp table ou Sending data e, em seguida, encerre-as com o comando kill.
Para mais informações, consulte Solutions for temporary file accumulation in RDS for MySQL.
Acúmulo de arquivos de log binário
Grandes transações geram muitos arquivos de log binário em um curto período. Se os logs se acumularem mais rápido do que são limpos, o armazenamento se esgota e a instância é bloqueada.
Resolva fazendo o upload dos logs existentes:
Use o recurso de upload de log binário com um clique para enviar arquivos de log binário da instância RDS para o OSS. O RDS exclui automaticamente os arquivos enviados. Consulte Visualizar e excluir arquivos de log binário.
Evite a recorrência ajustando a política de retenção:
No console do RDS, acesse a página Backup and Restoration.
Clique na aba Backup Strategy.
Ao lado de Local Log Retention Policy, clique em Edit.
Ajuste o período de retenção, o uso máximo de armazenamento e o espaço de armazenamento disponível. Quando o armazenamento de logs locais atinge o limiar, o sistema exclui os logs mais antigos automaticamente.
Para mais informações, consulte Solutions for MySQL binlog file accumulation.
Acúmulo de fragmentação
O InnoDB gerencia tablespaces por página. Quando você exclui ou atualiza linhas usando delete ou update, o MySQL marca o espaço como reutilizável, mas não reduz o arquivo em disco. Se as páginas liberadas não puderem ser reutilizadas, a fragmentação se acumula e consome armazenamento.
Resolva a fragmentação usando um dos seguintes métodos:
Linha de comando: Execute
optimize table <table_name>para reconstruir a tabela e recuperar o espaço fragmentado.Console do DMS: Faça logon na instância RDS no DMS. Clique com o botão direito no nome de uma tabela e escolha Batch operation table. Selecione as tabelas para desfragmentar e, em seguida, escolha Table Maintenance > Optimize Table.
Automatic reclamation: No console do RDS, acesse Autonomy Services > Diagnostics > Autonomy Center. Clique em Autonomy Service Settings e, em seguida, ative Automatic Fragment Reclamation na aba Optimization and Throttling. Para obter detalhes, consulte Usar o recurso de recuperação automática de fragmentos.
Para mais informações, consulte Solutions for MySQL space fragmentation.
Acúmulo de arquivos de sistema
Arquivos de sistema grandes são quase sempre causados pelo crescimento do undo log. Quando consultas InnoDB de longa duração são executadas simultaneamente com grandes atualizações de dados, o MySQL gera grandes quantidades de dados de undo. Esses dados preenchem o tablespace do sistema e podem esgotar o armazenamento.
A resolução depende da sua versão do MySQL e da configuração do tablespace de undo.
MySQL 8.0
O sistema limpa automaticamente os arquivos de undo. Nenhuma ação manual é necessária.
**MySQL 5.7 com innodb_undo_tablespaces = 2**
A instância usa tablespaces de undo separados. Quando o tamanho do arquivo de undo excede innodb_max_undo_log_size e nenhuma transação ativa requer os dados, o sistema executa uma operação truncate para liberar o espaço.
**MySQL 5.7 com innodb_undo_tablespaces = 0**
Os dados de undo são armazenados no tablespace do sistema ibdata1 e não podem ser recuperados. Use um dos seguintes métodos para resolver o problema:
Método 1: Crie uma nova instância e migre os dados usando o DTS. Consulte Data migration through the RDS MySQL console.
Método 2: Atualize para o MySQL 8.0. Consulte Upgrade the database version.
MySQL 5.5 e 5.6
A limpeza de arquivos de undo não é suportada. Atualize para o MySQL 5.7 High-availability Edition ou MySQL 8.0. Após atualizar para o MySQL 5.7, ative tablespaces de undo separados para suportar a limpeza automática. O MySQL 8.0 limpa os arquivos de undo automaticamente.
Para instâncias do MySQL 5.7 ou anteriores onde innodb_undo_tablespaces = 0, o espaço usado pelo arquivo ibdata1 original não pode ser recuperado mesmo após uma atualização de versão principal. Após a atualização, apenas os logs de undo recém-gerados são gravados em tablespaces separados e suportam limpeza automática.
Para mais informações, consulte Solutions for MySQL system file accumulation.
Acúmulo de arquivos de general log
Quando o general query log está ativado, o RDS registra cada instrução SQL executada, incluindo SELECT, INSERT, UPDATE e DELETE. Sob alto tráfego, o arquivo de log cresce rapidamente. Se não for limpo regularmente, pode esgotar o armazenamento.
Resolva imediatamente:
Execute o seguinte comando e exclua todos os registros de general log existentes:
TRUNCATE TABLE mysql.general_log;Interrompa o crescimento de novos logs:
Desative a coleta de general log e defina o parâmetro de tempo de execução general_log como OFF. Consulte Definir parâmetros da instância.
Melhor prática: Mantenha o general log desativado em produção. Ative-o temporariamente apenas para depuração ou solução de problemas e, em seguida, desative-o e limpe imediatamente depois.
Para mais informações, consulte Solutions for MySQL general log file accumulation.
Acúmulo de arquivos de dados do usuário
Os arquivos de dados do usuário crescem ao longo do tempo e podem preencher o armazenamento se não forem gerenciados. Colunas com tipos blob, text ou varchar longo são contribuintes comuns para grandes tamanhos de arquivos de dados. Quando o armazenamento está cheio, o RDS bloqueia a instância para evitar a perda de dados.
Resolva limpando os dados não utilizados:
Use
dropoutruncatepara remover tabelas ou dados que não são mais necessários.Para dados de objetos grandes, compacte os dados antes de armazená-los para reduzir o uso de espaço.
Para mais informações, consulte Solutions for RDS for MySQL data file accumulation.
Acúmulo de arquivos de índice
Os índices de banco de dados são armazenados como arquivos em disco. Uma política de indexação ineficiente ou um grande número de índices secundários pode fazer com que os arquivos de índice cresçam e esgotem o armazenamento.
Otimize sua estratégia de indexação:
Crie índices em campos apropriados: Crie índices em campos que são frequentemente consultados, classificados ou usados em junções de tabelas. Use índices compostos em vez de índices de coluna única sempre que possível para reduzir o tamanho total do arquivo de índice.
Remova índices não utilizados: Exclua índices que são redundantes ou que não são mais referenciados por nenhuma consulta.
A exclusão de um índice pode causar bloqueio no nível da tabela. Execute esta operação durante horários de menor movimento ou use o recurso lock-free schema evolution no DMS para reduzir o impacto.