Streaming do PostgreSQL pg_dump para S3

Question

É possível ou aconselhável enviar / enviar a saída pg_dump para o S3?

Estamos despejando grandes conjuntos de dados em nossa instância e o tamanho do banco de dados é grande. Portanto, tente otimizar o espaço em disco local (evite espaço temporário para o despejo) e crie o backup diretamente no S3.

Temos um PostgreSQL v9.6.3 no Ubuntu 16.04.

    

Answer 1

Você pode usar o recurso de upload multiparte do s3 para transmitir o despejo como está sendo gerado. No entanto, é provável que isso seja propenso a erros e menos confiável. Uma abordagem melhor é criar um volume EBS efêmero, despejar seu banco de dados para ele. E, em seguida, faça o upload do backup compactado para s3 / Glacier, se é onde ele precisa ir.

Se você estiver querendo um backup para recuperação pontual fazendo um pg_basebackup em um volume do EBS e arquivando o fluxo do WAL a partir do ponto após o backup, poderá reduzir o tempo de recuperação sem manter um nó completo de réplica. Se a sua preocupação é a disponibilidade, então configurar a replicação é o caminho a percorrer. Embora você ainda queira backups.

A replicação não é backup, se alguém deixar cair uma tabela na Origem, ela será descartada na réplica; então você ainda precisa de backups PITR ou de ponto de verificação.

    

Answer 2

O streaming do pg_dump diretamente para o S3 parece funcionar bem. Eu tenho banco de dados de 350GB e não quero criar unidades adicionais temp. Você precisa ter certeza de que o tamanho do pedaço de multipartes é grande o suficiente, caso contrário, eu encontrei um problema de "muitos segmentos". Com o AWS CLI, os comandos:

aws configure set default.s3.multipart_chunksize 200MB 
time sudo -u postgres pg_dump -Z 9 -v DB_NAME |aws s3 cp - s3://BUCKET/DB_NAME.dump.gz

Com o meu banco demorou cerca de 8 horas e o resultado foi de 130GB no S3. Agora a restauração deve ser feita com o psql, já que o pg_restore não gosta do sql dumps simples que o comando acima cria. Eu não pude usar o formato personalizado lá, pois isso quer criar diretórios que não podem (provavelmente?) Ser canalizados.

Finalmente restaurando da mesma maneira, sem salvar arquivos intermediários. Note que eu tive que descompactar os dados antes do psql usando zcat:

wget -O - 'https://S3-URL/BUCKET/DB_NAME.dump.gz' |zcat |sudo -u postgres psql DB_NAME

A restauração parece levar aproximadamente o mesmo tempo (~ 8 horas) que o dumping, provavelmente depende de onde e quão grande é o seu servidor (AWS ou outro lugar, o meu está fora da AWS).

    

Answer 3

Não, não é sábio. Em vez disso, configure a replicação real suportada pelo PostgreSQL. Eu usaria o modelo de assinante, mas você também pode fazer o envio de logs do WAL para s3 se quiser usar archive_command .

No entanto, isso é principalmente desnecessário. Eu não consideraria isso a menos que eu tivesse mais um caso de uso especial.

Eu atualizaria para 10.1 e pularia na replicação lógica com o modelo de assinante.