Meu banco de dados PostgreSQL está sem espaço em disco

O espaço em disco é um recurso exigente hoje em dia. Normalmente, você deseja armazenar dados o maior tempo possível, mas isso pode ser um problema se você não tomar as medidas necessárias para evitar um possível problema de “falta de espaço em disco”.

Neste blog, veremos como podemos detectar esse problema no PostgreSQL, preveni-lo e, se for tarde demais, algumas opções que provavelmente ajudarão você a corrigi-lo.

Como identificar problemas de espaço em disco do PostgreSQL

Se você, infelizmente, estiver nessa situação de falta de espaço em disco, poderá ver alguns erros nos logs do banco de dados PostgreSQL:

2020-02-20 19:18:18.131 UTC [4400] LOG:  could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on device

ou até mesmo no log do seu sistema:

Feb 20 19:29:26 blog-pg1 rsyslogd: imjournal: fclose() failed for path: '/var/lib/rsyslog/imjournal.state.tmp': No space left on device [v8.24.0-41.el7_7.2 try http://www.rsyslog.com/e/2027 ]

O PostgreSQL pode continuar funcionando por algum tempo executando consultas somente leitura, mas eventualmente, ele falhará ao tentar gravar no disco, então você verá algo assim na sua sessão do cliente:

WARNING:  terminating connection because of crash of another server process

DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

HINT:  In a moment you should be able to reconnect to the database and repeat your command.

server closed the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

The connection to the server was lost. Attempting reset: Failed.

Então, se você der uma olhada no espaço em disco, você terá essa saída indesejada…

$ df -h

Filesystem                        Size Used Avail Use% Mounted on

/dev/mapper/pve-vm--125--disk--0   30G 30G 0 100% /

Como evitar problemas de espaço em disco do PostgreSQL

A principal maneira de evitar esse tipo de problema é monitorar o uso do espaço em disco e o crescimento do uso do banco de dados ou do disco. Para isso, um gráfico deve ser uma maneira amigável de monitorar o incremento de espaço em disco:

E o mesmo para o crescimento do banco de dados:

Outra coisa importante a ser monitorada é o status da replicação. Se você tiver uma réplica e, por algum motivo, ela parar de funcionar, dependendo da configuração, pode ser possível que o PostgreSQL armazene todos os arquivos WAL para restaurar a réplica quando ela voltar.

Todo esse sistema de monitoramento não faz sentido sem um sistema de alerta para saber quando você precisa tomar medidas:

Como corrigir problemas de espaço em disco do PostgreSQL

Bem, se você está enfrentando esse problema de falta de espaço em disco mesmo com o sistema de monitoramento e alerta implementado (ou não), há muitas opções para tentar corrigir esse problema sem perda de dados (ou menos que possível).

O que está consumindo seu espaço em disco?

O primeiro passo deve ser determinar onde está meu espaço em disco. Uma prática recomendada é ter partições separadas, pelo menos uma partição separada para o armazenamento do banco de dados, para que você possa confirmar facilmente se o banco de dados ou o sistema está usando espaço em disco excessivo. Outra vantagem disso é minimizar os danos. Se sua partição raiz estiver cheia, seu banco de dados ainda poderá gravar em sua própria partição sem problemas.

Uso do espaço do banco de dados

Vamos ver agora alguns comandos úteis para verificar o uso do espaço em disco do banco de dados.

Uma maneira básica de verificar o uso do espaço do banco de dados é verificar o diretório de dados no sistema de arquivos:

$ du -sh /var/lib/pgsql/11/data/

819M /var/lib/pgsql/11/data/

Ou se você tiver uma partição separada para seu diretório de dados, você pode usar df -h diretamente.

O comando do PostgreSQL “\l+” lista os bancos de dados adicionando as informações de tamanho:

$ postgres=# \l+

                                                               List of databases

   Name    | Owner   | Encoding | Collate | Ctype |   Access privileges | Size | Tablespace

|                Description

-----------+----------+-----------+---------+-------+-----------------------+---------+------------

+--------------------------------------------

 postgres  | postgres | SQL_ASCII | C       | C | | 7965 kB | pg_default

| default administrative connection database

 template0 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| unmodifiable empty database

           |          | |         | | postgres=CTc/postgres |         |

|

 template1 | postgres | SQL_ASCII | C       | C | =c/postgres +| 7817 kB | pg_default

| default template for new databases

           |          | |         | | postgres=CTc/postgres |         |

|

 world     | postgres | SQL_ASCII | C       | C | | 8629 kB | pg_default

|

(4 rows)

Usando pg_database_size e o nome do banco de dados, você pode ver o tamanho do banco de dados:

postgres=# SELECT pg_database_size('world');

 pg_database_size

------------------

          8835743

(1 row)

E usar o pg_size_pretty para ver esse valor de forma legível pode ser ainda melhor:

postgres=# SELECT pg_size_pretty(pg_database_size('world'));

 pg_size_pretty

----------------

 8629 kB

(1 row)

Quando você souber onde está o espaço, poderá executar a ação correspondente para corrigi-lo. Tenha em mente que apenas excluir linhas não é suficiente para recuperar o espaço em disco, você precisará executar um VACUUM ou VACUUM FULL para concluir a tarefa.

Arquivos de registro

A maneira mais fácil de recuperar espaço em disco é excluindo arquivos de log. Você pode verificar o diretório de log do PostgreSQL ou até mesmo os logs do sistema para verificar se pode ganhar algum espaço a partir daí. Se você tiver algo assim:

$ du -sh /var/lib/pgsql/11/data/log/

18G /var/lib/pgsql/11/data/log/

Você deve verificar o conteúdo do diretório para ver se há um problema de rotação/retenção de log ou algo está acontecendo em seu banco de dados e gravá-lo nos logs.

$ ls -lah /var/lib/pgsql/11/data/log/

total 18G

drwx------  2 postgres postgres 4.0K Feb 21 00:00 .

drwx------ 21 postgres postgres 4.0K Feb 21 00:00 ..

-rw-------  1 postgres postgres  18G Feb 21 14:46 postgresql-Fri.log

-rw-------  1 postgres postgres 9.3K Feb 20 22:52 postgresql-Thu.log

-rw-------  1 postgres postgres 3.3K Feb 19 22:36 postgresql-Wed.log

Antes de excluir os logs, se você tiver um muito grande, uma boa prática é manter as últimas 100 linhas ou algo assim, e depois excluí-lo. Assim, você pode verificar o que está acontecendo depois de gerar espaço livre.

$ tail -100 postgresql-Fri.log > /tmp/log_temp.log

E então:

$ cat /dev/null > /var/lib/pgsql/11/data/log/postgresql-Fri.log

Se você apenas deletar com “rm” e o arquivo de log estiver sendo usado pelo servidor PostgreSQL (ou outro serviço) o espaço não será liberado, então você deve truncar este arquivo usando este cat / comando dev/null em vez disso.

Esta ação é apenas para arquivos de log do PostgreSQL e do sistema. Não exclua o conteúdo pg_wal ou outro arquivo PostgreSQL, pois isso pode gerar danos críticos ao seu banco de dados.

Inchar

Em uma operação normal do PostgreSQL, as tuplas excluídas ou obsoletas por uma atualização não são removidas fisicamente da tabela; eles estão presentes até que um VACUUM seja executado. Portanto, é necessário fazer o VACUUM periodicamente (AUTOVACUUM), principalmente em tabelas atualizadas com frequência.

O problema aqui é que o espaço não é devolvido ao sistema operacional usando apenas VACUUM, ele só está disponível para uso na mesma tabela.

VACUUM FULL regrava a tabela em um novo arquivo de disco, retornando o espaço não utilizado ao sistema operacional. Infelizmente, ele requer um bloqueio exclusivo em cada tabela enquanto está em execução.

Você deve verificar as tabelas para ver se um processo VACUUM (FULL) é necessário.

Slots de replicação

Se você estiver usando slots de replicação e não estiver ativo por algum motivo:

postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;

 slot_name | slot_type | active

-----------+-----------+--------

 slot1     | physical  | f

(1 row)

Pode ser um problema para o seu espaço em disco, pois ele armazenará os arquivos WAL até que sejam recebidos por todos os nós em espera.

A maneira de corrigir é recuperando a réplica (se possível) ou excluindo o slot:

postgres=# SELECT pg_drop_replication_slot('slot1');

 pg_drop_replication_slot

--------------------------

(1 row)

Assim, o espaço utilizado pelos arquivos WAL será liberado.

Conclusão