PG_Dump Falha devido ao baixo espaço em disco com erros

Question

Estou tentando usar o pg_dump no meu localhost para despejar um banco de dados PostgreSQL de 4GB em uma máquina remota. Meu localhost informa 15GB de espaço disponível. Estou canalizando a saída para o gzip. No entanto, após cerca de 15 minutos de processamento, pg_dump anula, afirmando "pg_dump: [tar archiver] não pôde gravar no arquivo de saída: não há espaço no dispositivo". Eu monitora continuamente a quantidade de espaço livre em disco na minha máquina e ela permanece sempre na faixa de ~ 10GB. Por que o pg_dump falha prematuramente devido ao pouco espaço em disco, embora ainda haja muito espaço?

Meu comando parece:

pg_dump -c --host=${HOST} --username=${DATABASEUSER} --blobs --format=t ${DATABASE} | gzip -c > /tmp/db-backup.tar.gz

    

Answer 1

Eu sugiro mudar o formato do dump para custom (-Fc, --format c) e evitar o formato tar. AFAIK não há vantagens de usar o formato tar em vez de custom (ambos funcionam com o pg_restore).

Reading between the lines, I suspect you are trying to use 'tar' output format, which does have a need to make temp files that can be large. If I guessed right, I'd suggest using 'custom' format instead. There really is no advantage to tar format, and several disadvantages besides this one.

de link

Se a sua instalação vier do pacote, provavelmente você terá suporte ao formato personalizado (zlib) "fora da caixa". Você pode controlar o nível de compactação com a opção -Z (o valor padrão é 6) de 0 (sem compactação) para 9.

BTW, verifique sua opção -c. De acordo com o link

Output commands to clean (drop) database objects prior to (the commands for) creating them.

This option is only meaningful for the plain-text format. For the archive formats, you can specify the option when you call pg_restore.

BTW2 Por conveniência, você pode usar variáveis de ambiente automáticas do PostgreSQL, como PGHOST, PGUSER, PGDATABASE, PGPORT.

    

Answer 2

O formato tar pg_dump no PostgreSQL limita o tamanho de qualquer tabela a 8GB, antes que a compactação seja aplicada. E um banco de dados de 4GB não vai despejar em um arquivo de 4GB; o formato de texto será maior para alguns tipos de dados, e desde que eu vejo você despejando blobs você poderia facilmente estar nessa categoria. Então, outra possibilidade é que você tenha uma mesa com, digamos, 3GB; expande para > 8 GB quando descarregado; e você está atingindo o limite de alcatrão, que é imposto antes que a compactação seja ativada. Dumping em texto simples ou o formato personalizado eliminaria seu problema se isso fosse o que estava acontecendo.

A outra possibilidade é que sua unidade seja dimensionada de tal forma que ~ 10GB represente cerca de 5% dela. Se a sua partição tiver cerca de 200 GB, você poderá estar atingindo o limite em que 5% do espaço é reservado para o root no ext4. Você pode eliminar isso usando algo assim se for esse o caso:

sudo tune2fs -m 0 /dev/sda1