Como impedir que um contentor de base de dados continue a aumentar após a limpeza dos dados

Um contentor de base de dados pode continuar a crescer após a limpeza dos dados, porque as linhas eliminadas, os registos de transações, os índices e os registos do contentor seguem regras diferentes de recuperação de espaço.

Não assuma que o volume da base de dados está a crescer apenas porque o espaço total ocupado pelo contentor aumenta. Meça separadamente o diretório de dados da base de dados, os diretórios WAL ou binlog, o ficheiro de registo do Docker, a camada gravável e os caminhos de cópia de segurança ou temporários. Depois, determine se o espaço eliminado da base de dados pode ser reutilizado internamente, mas não devolvido ao anfitrião, se é realmente necessária uma reescrita ou se existe outro ficheiro completamente diferente que continua a crescer.

Meça Qual o Caminho Que Continua a Crescer

Registe o tamanho do volume nomeado ou do diretório da base de dados montado por bind, da camada gravável do contentor, do registo do contentor no anfitrião, do diretório de registos de transações da base de dados e de qualquer diretório de despejos ou temporário, antes e depois de um ciclo de limpeza.

Um guia de resolução de problemas relacionados com o espaço em disco do PostgreSQL começa pelo mesmo princípio: descubra onde está o espaço antes de escolher uma operação de recuperação.

Se apenas o registo do Docker crescer, a limpeza da base de dados é irrelevante. Se o ficheiro de dados continuar grande, mas parar de aumentar após a limpeza, o motor pode já estar a reutilizar páginas libertadas, mesmo que o sistema de ficheiros do anfitrião não mostre qualquer redução.

Diferencie o Espaço Reutilizável da Base de Dados do Espaço Devolvido ao Disco

Muitas bases de dados transacionais não removem imediatamente os blocos de ficheiros do meio de uma tabela depois de as linhas serem eliminadas. Marcam ou recuperam páginas internas para que as inserções posteriores possam reutilizar esse espaço, enquanto o ficheiro subjacente mantém o mesmo tamanho.

O PostgreSQL fornece um exemplo claro: o VACUUM reutiliza o espaço internamente, mas normalmente não devolve essas regiões intermédias do ficheiro ao sistema operativo.

Observe se o ficheiro continua a crescer durante novas inserções após a limpeza. Um tamanho de ficheiro estável, com a fragmentação interna a diminuir, é diferente de um crescimento descontrolado e normalmente não justifica uma reescrita de emergência.

Utilize o Método de Recuperação do Motor da Base de Dados, Não uma Limpeza Genérica do Docker

Quando o objetivo é devolver capacidade ao anfitrião, identifique primeiro o motor e o formato de armazenamento. PostgreSQL, MySQL ou MariaDB e SQLite não utilizam um único comando de redução intercambiável, e algumas operações de recuperação reescrevem ficheiros grandes ou bloqueiam tabelas.

Um artigo sobre armazenamento do MySQL explica como o OPTIMIZE pode reconstruir tabelas InnoDB, em vez de tratar um DELETE como prova de que o anfitrião deve recuperar imediatamente esses bytes.

Faça uma cópia de segurança da base de dados e confirme que existe espaço de trabalho livre antes de qualquer operação que exija uma reescrita. Um sistema de ficheiros de um servidor doméstico quase cheio é o pior momento para iniciar um comando que precisa de uma segunda cópia de uma tabela grande.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique Separadamente o WAL, os Binlogs e a Retenção da Replicação

Os registos de transações podem crescer mesmo depois de as linhas antigas da aplicação serem eliminadas. Um trabalho de arquivo com falhas, um espaço de replicação obsoleto, uma réplica atrasada, uma transação longa ou um requisito de retenção de cópias de segurança podem manter segmentos históricos de registos no disco.

Uma nota recente sobre recuperação do PostgreSQL mostra como a retenção do WAL pode consumir armazenamento de forma independente dos dados das tabelas que um utilizador acabou de limpar.

Não elimine manualmente ficheiros WAL ou binlog do sistema de ficheiros. Corrija a causa da retenção através do motor da base de dados e confirme depois que a reciclagem normal foi retomada.

Limite os Registos do Docker e Verifique a Camada Gravável

Um contentor de base de dados pode parecer estar a crescer porque a saída stdout ou stderr é capturada num registo Docker sem limite, ou porque uma exportação temporária, uma cache ou um ficheiro da base de dados foi escrito na camada do contentor, em vez do volume persistente pretendido.

Um caso relacionado com Docker autoalojado observa que os registos dos contentores podem crescer indefinidamente quando a rotação não está configurada.

Associe cada ficheiro grande no anfitrião ao respetivo caminho dentro do contentor antes de eliminar qualquer conteúdo. Configure a rotação dos registos para evitar crescimento futuro e mova o estado da base de dados para um volume explícito, em vez de depender da camada gravável efémera.

Confirme Que a Limpeza Cria Margem Sustentável

Após o passo de recuperação escolhido, execute a carga de escrita normal durante um período representativo e compare o espaço livre no anfitrião, o tamanho dos ficheiros da base de dados, o tamanho dos registos de transações, os registos do Docker e as métricas internas de espaço livre ou fragmentação.

Um guia de redução do armazenamento do PostgreSQL salienta que a redução exige manutenção direcionada, em vez de assumir que cada eliminação deve reduzir imediatamente o tamanho do ficheiro no sistema operativo.

A correção está concluída quando o crescimento esperado da base de dados é reutilizado ou limitado e o anfitrião deixa de perder capacidade inexplicada após cada ciclo de limpeza. O guia relacionado da ZimaSpace sobre cópias de segurança consistentes de contentores de bases de dados fornece o ponto de recuperação antes de qualquer operação que reescreva ficheiros da base de dados.

Perguntas Frequentes

Porque é que eliminar milhões de linhas por vezes liberta muito pouco espaço no disco do anfitrião?

O motor pode marcar essas páginas como reutilizáveis dentro do ficheiro da base de dados, em vez de truncar o próprio ficheiro. Isso pode impedir um crescimento futuro sem alterar o tamanho visível do ficheiro no anfitrião.

Devo executar uma reescrita completa sempre que o contentor fica grande?

Não. As operações que exigem muita reescrita podem necessitar de bloqueios, espaço temporário e uma quantidade significativa de E/S. Utilize-as apenas quando for necessário devolver espaço ao anfitrião e quando os riscos específicos do motor forem compreendidos.

A limpeza do Docker pode recuperar um volume de base de dados?

Não de forma segura quando o volume ainda faz parte do estado persistente da base de dados. Identifique se o espaço pertence a registos, imagens, contentores parados ou dados ativos da base de dados antes de executar a limpeza.