Como minimizar a largura de banda no cenário de backup frequente de postgres?

Question

Eu estou olhando para fazer backup muito freqüente (a cada hora) de dados postgres em várias VMs (digamos 20-50) para o mesmo servidor de arquivamento.

Aqui estão mais dados, se necessário: Idealmente, o sistema deve suportar a carga de 80 a 200 bancos de dados localizados em todas as VMs. As bases de dados são pequenas (10MB - 100MB) a médias (500MB - 2GB), compostas por centenas de tabelas, uma pequena porção destas tabelas pode conter facilmente vários milhares de linhas até cerca de um milhão de linhas. Mudanças no banco de dados geralmente são novos registros, algumas atualizações, e não tanto exclusão. A largura de banda seria de 100 Mbits / s.

Como eu já estou fazendo isso com um sistema de arquivos padrão usando backup incremental ( rsync ), estou pensando se algo semelhante poderia ser alcançado com backups de banco de dados postgres.

Eu tenho várias opções possíveis:

• Eu poderia optar por colocar o banco de dados no sistema de arquivos instantâneo ( aufs docker style, ZFS , btrfs , mas alguns deles parecem realmente estar diminuindo o tamanho do postgres).
• Estou pronto para usar o WAL, se necessário
• Seria melhor se eu pudesse fazer backup apenas no nível do banco de dados, se necessário. Como eu não preciso fazer backup de todos os dados do postgres, apenas os bancos de dados dos clientes.
• Eu tenho algum espaço em disco no servidor postgres que poderia manter um backup intermediário.
• Eu posso pagar uma certa carga de trabalho de CPU razoável no lado da VM, mas prefiro minimizá-la no servidor de backup, pois isso adicionará mais banco de dados ao backup que haverá.
• Eu não estou realmente procurando opções de backup contínuo ou recuperação de PITR. Meu servidor de backup tem um sistema baseado em arquivo (brfs) para fazer instantâneos periódicos eficientes de backups. É bom o suficiente.

Eu pensei sobre:

• usando rsync em combinação com pg_dump localmente para o servidor no SQL, mas não sei qual dos formatos diferentes devo usar para manter a máxima eficiência.
• usando o sistema de arquivos instantâneo que permite enviar diffs binários no nível de bloco (btrfs e ZFS são bons nisso) com ou sem o uso de um dump local (a mesma pergunta sobre o formato de backup a ser usado).
• Eu aprendi sobre a existência de pg_rman , eu realmente não sei se pode ser confiável, e a configuração e vários processos parecem um pouco mais pesados do que pg_dump . Suportaria ter apenas backups incrementais? E podemos ter um formato prático no lado de backup?.

e existe outra maneira de backups incrementais para alcançar pequenas bandas?

Então ... como eu poderia diminuir a largura de banda no meu cenário de backup de postgres ?

    

Answer 1

Você está tentando resolver um problema bem praticado (em sistemas reais de banco de dados) usando uma solução inábil; isso é compreensível para a maioria das pessoas que vem de um segundo plano em sistemas de banco de dados menores (e eu fiz uma coisa muito parecida com o MySQL e corrijo pelas conseqüências do blowout de largura de banda).

Você deve usar os recursos de replicação do PostgreSQL; veja link

    

Answer 2

Faça o despejo no formato sql. Mantenha uma cópia completa na vm local, digamos atualizada todos os dias. Então, copie uma nova cópia e faça um diff a partir da cópia completa. Copie a cópia completa uma vez por dia e só difira em outros momentos. Para restaurar, você terá que corrigir a cópia completa com um diff e executar o arquivo sql.