2015-01-23 11:15 GMT-02:00 André Ormenese <[email protected]>:

> Agora fiquei mais confuso.... então eu estava certo com relação ao
> pg_xlog, mas a coisa realmente não anda se eu apagar o conteúdo desta pasta.
>
>
>  Seguem os comandos para o backup e restore :
>
> - Backup ( não vou colocar o script inteiro para não poluir muito )
>
>
>
Nossa. Tem tanta coisa estranha nesse script que nem sei se vou pegar tudo,
mas vou comentar os pontos mais críticos (de qualquer forma recomendo
começar do zero, e usar o pg_basebackup):


> [...]
>
> $PATHEXE/bin/psql --echo-all -U postgres >> $ARQ_LOG << fim_psql
>
> select pg_start_backup('$1');
>
>
>
Ok.


> #Apaga registro do backup produzido pelo PostgreSQL
>
> rm $DIR_BASE/data/pg_xlog/archive_status/*.*.backup.done
>
> rm $DIR_BASE/data/pg_xlog/*.*.backup
>
>
>
Por que você está fazendo isso?

Vide regra, nunca, em hipótese alguma, nunca remova, mova, edite, nenhum
arquivo dentro do diretório pg_xlog do banco que está em funcionamento.
NUNCA!

OBS: De fato não me parece que esse caso específico causaria muito
problemas, mas não posso afirmar sem mais investigação.

 …
>
> #veja que já estou desconsiderando o pg_xlog na cópia dos arquivos de
> dados
>
> tar -cvf $DIR_BASE/data/$NOME_ARQ_BKP --check-links --exclude
> $PGDATA/pg_xlog $PGDATA
>
>
Ok. Me parece uma boa nem incluir o pg_xlog.


>
> $PATHEXE/bin/psql --echo-all -U postgres >> $ARQ_LOG
>
> select pg_stop_backup();
>
>
>

Ok.


>
> tar -cvf $DIR_BASE/data/$ARQ_BKP_WAL --check-links $PATH_WAL | tee -a
> $ARQ_LOG
>
> rm $PATH_WAL/*
>
>
>
Não entendi muito o porquê está fazendo isso aqui. Como está seu
archive_command?


>  # Final do BACKUP
>
>
>  Para o restore fiz um script rápido, só para testar os passos da
> restauração. Ele é rodado como usuário postgres.
>
>
>  #! /bin/sh
>
> cd /dados/bancos/pg_hemo/data
>
>
>  ../9.3.4/bin/pg_ctl -D . stop
>
> # Apaga todos os arquivos do diretório de dados do banco e da pasta onde
> faz a cópia dos arquivos de WAL (caminho fornecido pelo archive_command)
>
> rm -rf *
>
> rm -rf /dados/wal/hemo/*
>
>
>  cd /
>
> tar -xvf /dados/bancos/pg_hemo/bk_hemo.tar
>
> tar -xvf /dados/bancos/pg_hemo/bk_hemo_wal.tar
>
>
>  #move os dados para a pasta restore porque o recovery.conf vai consumir
> os logs nesta pasta.
>
> mv /dados/wal/hemo/* /dados/wal/restore
>
>
>
Isso também está um tanto obscuro. Talvez devemos entender como está
fazendo o arquivamento (archive_command).


>  cd /dados/bancos/pg_hemo/data
>
> rm backup_label
>

Ha.

*AQUI ESTÁ O ERRO PRINCIPAL.*
Como eu havia suspeitado antes (pelo erro no log) você está apagando o
backup_label. Não é a primeira vez que vejo isso sendo feito, sabe me dizer
se tem algum guia em algum lugar que pede para fazer isso? Porque está
completamente errado, e se um dia funcionou com isso foi por acidente/sorte.


> rm postmaster.pid
>
> rm logpost
>
> rm recovery.done
>
> rm ./pg_log/*
>
>
>  mkdir pg_xlog
>
> cd pg_xlog
>
> mkdir archive_status
>
> cd ..
>
> cp /home/postgres/recovery.conf /dados/bancos/pg_hemo/data/
>
>
>  #copia os arquivos WAL da produção para deixar o banco com todas as
> atualizações.
>
> #não se preocupe com esta situação... num problema de perder a máquina da
> produção, tenho
>
> #outra como slave, e que tem uma cópia destes arquivos também
>
>
> scp [email protected]:/dados/wal/hemo/'0*' /dados/wal/restore/
>
> scp [email protected]:/dados/wal/hemo/atual/'0*' /dados/wal/restore/
>
>
>
Não olhei detalhadamente, mas me parece OK.


> #se eu não fizer este procedimento abaixo, tenho aquelas mensagens de
> invalid primary checkpoint record. O banco não sobe,  os arquivos de log
> não são consumidos e é gerado um arquivo postgres.core até que grande (+- 1
> GB).
>
> cp /dados/wal/restore/0* /dados/bancos/pg_hemo/data/pg_xlog/
>
>
>
Isso é necessário porque você está apagando o backup_label, o ideal é
manter o backup_label e deixar o PostgreSQL fazer as cópias necessárias
pelo restore_command.

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

Responder a