Início / dba / Perguntas / 167515
Accepted
Hassan Baig
Asked: 2017-03-19 05:06:09 +0800 CST

Lidando com espaço em disco cheio no postgresql

  • 772

Eu tenho um aplicativo da web Django com backend postgresql 9.3.10 (sentado em um sistema operacional Linux). Eu encontrei um erro de disco cheio, de modo que, mesmo se eu tentar truncar uma tabela, recebo erros do tipo:

ERROR:  could not extend file "base/30137/33186048": No space left on device
HINT:  Check free disk space.

Não consigo adicionar facilmente mais espaço em disco ao servidor, nem posso excluir coisas nesta VM. No entanto, existem várias tabelas que são candidatas ao truncamento, mas parece que também não posso truncá-las agora.

Alguém pode me dar uma dica do que posso fazer aqui? Isso está afetando muito meu servidor de produção, e eu sou um DBA acidental aqui, totalmente perplexo.

postgresql postgresql-9.3

2 respostas

  1. Best Answer

    Como o PostgreSQL deve escrever WAL antes de fazer qualquer alteração nas tabelas, ele precisa de espaço livre em disco para excluir coisas e liberar mais espaço em disco.

    Se você deixar o disco ficar cheio, não poderá recuperar a partir do PostgreSQL. Mesmo TRUNCATEainda tem que escrever para WAL.

    Portanto, você deve liberar algum espaço no volume ou expandir o volume. Se seus arquivos de log do PostgreSQL estiverem no pg_logdiretório de dados, você pode remover alguns deles com segurança e reiniciar o Pg.

    Não exclua ou . _ Estes não são logs de erros do servidor, são partes críticas do banco de dados, o log de transações e o log de confirmação.pg_xlogpg_clog

    • 15

  2. Mais algumas ideias sobre como liberar espaço em disco em caso de emergência:

    • Se possível, evite que novas conexões de cliente sejam feitas.
    • Se possível, cancele comandos de execução não críticos ( SELECT, COPY IN, COPY OUT, CREATE INDEX, ...): não é garantido que ajude, mas pode em alguns casos.
      1. Use Pg_Cancel_Backend(<PID>)se você já tiver uma sessão privilegiada aberta ou apenas kill -s INT -- <PID>caso contrário.
    • Se possível, desconecte sessões não críticas, inativas ou ativas; novamente, não é garantido para ajudar, mas pode, em alguns casos.
      1. Use Pg_Terminate_Backend(<PID>)se você já tiver uma sessão privilegiada aberta ou apenas kill -s TERM -- <PID>caso contrário.
    • Se estiver usando pg_prewarmo módulo:
      1. Execute SET pg_prewarm.autoprewarm_interval = 0, se você já tiver uma sessão privilegiada aberta.
      2. rm -f <PGDATA>/autoprewarm.blocks
    • Se estiver usando pg_stat_statementso módulo e tiver uma sessão privilegiada aberta:
      1. Executar SELECT Pg_Stat_Statements_Reset().
    • Se tiver uma sessão privilegiada aberta:
      1. Executar SELECT Pg_Stat_Reset().
    • Se possível, elimine índices nos dados do usuário que são grandes o suficiente para serem importantes e podem definitivamente ser reconstruídos apenas a partir das linhas da tabela; comece com o maior.

    (Só para ficar claro: todas essas são medidas temporárias , não soluções de longo prazo ou mesmo de curto prazo!)

    • 1

relate perguntas