Como tornar o pg_dump menos recurso ganancioso

Question

Eu configurei o cron para invocar o pg_dump diariamente usando a seguinte regra:

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/'date -u +\%Y\%m\%dT\%H\%M\%S'.gz

Basicamente, funciona. O banco de dados cresce relativamente rápido e exponencialmente (no entanto, o expoente não é muito grande). Atualmente, o despejo gzipped leva cerca de 160MB. Quando o banco de dados é despejado, o sistema começa a rastrear. A média de carga que vi usando o comando top foi de cerca de 200, 200, 180 . Basicamente, o servidor dificilmente é responsivo.

A primeira pergunta é como determinar onde está o gargalo. O fraco desempenho é causado por operações pesadas de E / S? É causado por problemas de bloqueio de tabela? Talvez seja um problema de memória? A saída do comando pg_dump é canalizada para o comando gzip . É seqüencial, ou seja, todo o despejo é colocado na memória (problema de troca?) E, em seguida, compactado ou concorrente (ou seja, o gzip comprime o que obtém e aguarda por mais)? Pode ser causado por algum outro fator?

A segunda pergunta é como tornar a operação de dumping menos intrusiva para as principais funções do sistema. Tanto quanto eu entendo as coisas, o despejo não pode demorar muito por causa da integridade do banco de dados. Existem bloqueios de escrita de tabela, etc. O que posso fazer para limitar os problemas (ou atrasá-los, considerando o crescimento do banco de dados).

A terceira pergunta : Já é hora de aprender sobre configurações de banco de dados mais avançadas? O sistema funciona bem, quando backups de banco de dados não são realizados, mas talvez o problema de despejo do banco de dados seja um primeiro sintoma de problemas de entrada?

    

Answer 1

Uau. Incrível número de perguntas. Vou tentar abordar alguns, mas esta resposta ainda não está completa.

how to determine where the bottleneck is.

Use top primeiro para ver o que está acontecendo durante o despejo. Inspecione o uso da CPU do processo, o status do processo. D significa "esperando por E / S".

Is the poor performance caused by heavy I/O operations?

Sim, provavelmente.

Is it caused by table locking issues?

Talvez. você pode usar pg_stat_activity system view para ver o que está acontecendo no postgres durante o despejo.

Maybe it is a memory issue?

Muito improvável.

The output of the pg_dump command is piped to the gzip command. Is it sequential, i.e. entire dump is placed in the memory (swapping problem?)

Não. O gzip é um compressor de blocos que trabalha no modo stream, não mantém todas as entradas na memória.

and then compressed or concurrent (i.e. gzip compresses what it gets and waits for more)?

Sim, comprime bloco a bloco, gera e aguarda mais.

May it be caused by some other factor?

Sim.

As far as I understand things, the dump can't take too much time because of database integrity. There are table write locks, etc. What can I make to limit the problems (or delay it, considering database growth).

A duração do dump não tem efeito na integridade do dump. A integridade é garantida usando uma transação com o nível de isolamento repeatable read por todo o processo pg_dump. Não há bloqueios de gravação de tabela.

Is it already time to learn about more advanced database configurations? The system works ok, when database backups are not performed, but maybe the db dumping issue is a first symptom of incoming problems?

Nunca é tarde demais. Comece com link .

    

Answer 2

Eu recomendo que você olhe arquivamento contínuo do postgresql. Aqui estão as vantagens sobre o uso do pg_dump:

1. Não é necessário fazer um backup completo a cada vez. Um backup completo é suficiente no início, mas é recomendável ter um backup completo a cada vários dias, por exemplo.
2. Muito mais rápido para restaurar quando o BD aumenta de tamanho.
3. A capacidade de restaurar para algum outro ponto (Recuperação pontual).
4. Você fará backup incremental a cada hora (30 minutos ou mais). Isso pode ser configurado e depende também da atividade de atualização.

No entanto, existem algumas desvantagens (que podem não ser um problema na maioria dos casos):

1. Normalmente, é necessário mais espaço porque esses são backups binários. A pasta DB pode ser compactada.
2. Você não pode restaurá-los em uma arquitetura diferente (dados binários).