2013/8/30 Danilo Silva <[email protected]>
>
> [...]
>
> Realmente, quando você faz **só** um backup base, sem arquivamento, você
>>> irá precisar de todos os logs de transação gerados entre a chamada do
>>> pg_start_backup e pg_stop_backup. Em primeiro lugar, eu recomendaria você a
>>> tentar criar uma política de backup para PITR e habilitar **sempre** o
>>> arquivamento.
>>>
>>> Mas... De forma temporária, você pode fazer o seguinte:
>>>
>>> 1. Engane o PostgreSQL e habilite o arquivamento sem arquivar (loucura
>>> né?!):
>>>
>>> archive_mode = on
>>> archive_command = 'exit 0' # veja, não faz nada, só finge que copiou
>>>
>>> Reinicie o PostgreSQL (terás de reiniciar somente uma vez, por causa do
>>> archive_mode).
>>>
>>> 2. Quando for executar o backup base, configure o archive_command para
>>> efetivamente copiar os logs de transação:
>>>
>>> archive_command = 'cp %p /path/to/%f' # ou seu comando...
>>>
>>> Execute um reload no PostgreSQL (veja, não precisa de restart).
>>>
>>> 3. Realize sua cópia normalmente: pg_start_backup => cópia (tar, cp,
>>> etc.) => pg_stop_backup
>>>
>>> 4. Volte o archive_command para 'exit 0'
>>>
>>> Pronto, agora basta você "pegar" os arquivos salvos pelo archive_command
>>> "temporário" e salvá-los junto ao seu backup. Pode até colocá-los dentro do
>>> diretório pg_xlog do backup, ou, numa restauração você precisará somente
>>> configurar o restore_command no recovery.conf.
>>>
>>> Mais uma vez, vejo isso como algo temporário e rápido enquanto não
>>> define uma boa política de backup com arquivamento, pg_dump, etc...
>>>
>>> Era isso que eu precisava saber, vou testar e depois falo como foi.
>>
>>
>> Pessoal deu certo a dica do Matheus, agora surgiu outra dúvida:
>
> Preciso montar um script que execute o backup base, até então beleza, sem
> problemas, existe a possibilidade de colocar no script algum comando que
> altere a diretiva archive_command ou algo similar?
>
>
>
Eu faria de forma diferente, criaria um script para fazer o arquivamento
que verifique se um arquivo de trigger existe (acho que pode usar o próprio
backup_label), e, se existir, realiza a cópia, caso contrário não faz nada,
tipo assim:
#!/bin/sh
if [ -r backup_label ]; then
cp "$1" "$2"
exit $?
fi
exit 0
Daí você usa esse script no archive_command, tipo: archive_command =
"/path/to/archive.sh '%f' '/path/to/%p'".
OBS: IIRC, o diretório corrente ao executar o archive_command é o próprio
PGDATA, por isso usei o caminho relativo para encontrar o backup_label
(testar para confirmar).
Dessa forma somente quando o backup estiver em progresso é que o script
realmente copiará os logs de transação, caso contrário, o mesmo irá ignorar
e "fingir" que copiou.
PS: Mais uma vez, recomendo que, já que está tendo esse trabalho, faça o
arquivamento contínuo, experimente comprimir com gzip caso ache que está
ocupando muito espaço, verá que diminui +ou- para uns 20-30%.
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
