Quando uma instância do ApsaraDB RDS for MySQL esgota o espaço de armazenamento, ela é bloqueada automaticamente no modo somente leitura para evitar perda de dados. Identifique qual tipo de arquivo está consumindo espaço e resolva cada causa específica.
Resposta de emergência
Se a instância já estiver bloqueada (somente leitura), expanda o disco imediatamente para restaurar o acesso de escrita. Execute todas as limpezas e correções da causa raiz após a restauração do service.
No console do RDS, clique em ID da instância.
Redimensione o disco manualmente para desbloquear a instância.
A instância é desbloqueada em aproximadamente 5 minutos após a conclusão do redimensionamento. Acompanhe o progresso na Central de Tarefas.
O redimensionamento do disco é uma solução temporária. O armazenamento será preenchido novamente se você não resolver também a causa raiz descrita 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 em ID da instância.
No painel de navegação à esquerda, escolha Monitoring and Alerts > Standard Monitoring.
Localize a visualização MySQL Storage Space Used. Clique em í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 associe o parâmetro com alto uso ao tipo de arquivo e à solução correspondentes abaixo.
|
Tipo de arquivo |
Parâmetro no Standard Monitoring |
Parâmetro na Space Analysis |
Solução |
|
Arquivo temporário |
|
|
|
|
Arquivo 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 espaço significativo:
Fragmentação: consulte Acúmulo de fragmentação
Inchaço de índices: 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.
Resolver o bloqueio imediato:
MySQL 5.7 ou anterior: Reinicie a instância. 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 Copy to tmp table ou Sending data e encerre-as com o comando kill.
Para mais informações, consulte Soluções para acúmulo de arquivos temporários no 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.
Resolver fazendo upload dos logs existentes:
Utilize o recurso One-click binary log upload para enviar arquivos de log binário da instância do RDS para o OSS. O RDS exclui automaticamente os arquivos enviados. Consulte Visualizar e excluir arquivos de log binário.
Evitar reincidência ajustando a política de retenção:
No console do RDS, acesse a página Backup and Restoration.
Clique em 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 disponível. Quando o armazenamento local de logs atingir o limiar, o sistema exclui os logs mais antigos automaticamente.
Para mais informações, consulte Soluções para acúmulo de arquivos binlog do MySQL.
Acúmulo de fragmentação
O InnoDB gerencia tablespaces por página. Ao excluir ou atualizar 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 métodos a seguir:
Linha de comando: Execute
optimize table <table_name>para reconstruir a tabela e recuperar o espaço fragmentado.Console do DMS: Faça login na instância do 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 escolha Table Maintenance > Optimize Table.
Automatic reclamation: No console do RDS, acesse Autonomy Services > Diagnostics > Autonomy Center. Clique em Autonomy Service Settings e ative a Automatic Fragment Reclamation na aba Optimization and Throttling. Para detalhes, consulte Usar o recurso de recuperação automática de fragmentos.
Para mais informações, consulte Soluções para fragmentação de espaço no MySQL.
Acúmulo de arquivos de sistema
Arquivos de sistema grandes são quase sempre causados pelo crescimento do undo log. Quando consultas longas do InnoDB são executadas simultaneamente com grandes atualizações de dados, o MySQL gera dados de undo excessivos que 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 métodos a seguir para resolver o problema:
Método 1: Crie uma nova instância e migre os dados usando o DTS. Consulte Migração de dados pelo console do RDS MySQL.
Método 2: Atualize para o MySQL 8.0. Consulte Atualizar a versão do banco de dados.
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 original ibdata1 não pode ser recuperado mesmo após uma atualização de versão principal. Após a atualização, apenas novos logs de undo gerados são gravados em tablespaces separados e suportam limpeza automática.
Para mais informações, consulte Soluções para acúmulo de arquivos de sistema do MySQL.
Acúmulo de arquivos de general log
Quando o log geral de consultas 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.
Resolver imediatamente:
Execute o seguinte comando para excluir todos os registros existentes do general log:
TRUNCATE TABLE mysql.general_log;Interromper o crescimento de novos logs:
Desative a coleta do general log definindo 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, desative-o e faça a limpeza imediatamente depois.
Para mais informações, consulte Soluções para acúmulo de arquivos de general log do MySQL.
Acúmulo de arquivos de dados do usuário
Arquivos de dados do usuário crescem com o tempo e podem preencher o armazenamento se não forem gerenciados. Colunas com tipos blob, text ou varchar longo contribuem frequentemente para arquivos de dados grandes. Quando o armazenamento está cheio, o RDS bloqueia a instância para evitar perda de dados.
Resolver limpando dados não utilizados:
Use
dropoutruncatepara remover tabelas ou dados que não são mais necessários.Para dados de objetos grandes, comprima os dados antes de armazená-los para reduzir o uso de espaço.
Para mais informações, consulte Soluções para acúmulo de arquivos de dados no RDS for MySQL.
Acúmulo de arquivos de índice
Índices são armazenados como arquivos em disco. Uma estratégia de indexação ineficiente ou índices secundários excessivos podem 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 frequentemente consultados, classificados ou usados em junções de tabelas. Utilize í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 redundantes ou que não são mais referenciados por nenhuma consulta.
Excluir um índice pode causar bloqueio no nível da tabela. Realize esta operação fora do horário de pico ou use o recurso de evolução de esquema sem bloqueio no DMS para reduzir o impacto.