Em 23 de janeiro de 2015 12:23, Matheus de Oliveira < [email protected]> escreveu:
> > 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. > Como são arquivos de controle do backup imaginei não causar problemas. E até agora isso tem se confirmado. A base está em funcionamento e sem acusar nenhum problema nos logs. Mas de qualquer forma vou retirar esta remoção do script. > > … >> >> #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? > archive_command = 'test ! -f /dados/wal/hemo/"%f" && cp "%p" /dados/wal/hemo/"%f"' > > >> # 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). > Estou fazendo este "move" na máquina de restauração porque o archive_command está igual a máquina de produção ( archive_command = 'test ! -f /dados/wal/hemo/"%f" && cp "%p" /dados/wal/hemo/"%f"' ), e o restore_command está definido como : restore_command = 'cp /dados/wal/restore/%f %p' > > >> 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. > Pois é Matheus, pura ignorância !!! Como o backup_label é apagado após pg_stop_backup(), achei que ele não seria utilizado para situações de recover. > <corte> > > >> #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. > Matou a charada !!! Agora o recovery consome os arquivos de log, renomeia o recovery.conf para recovery.done, e também renomeia o backup_label para backup_label.old. Valeu Matheus... muito obrigado pela ajuda !!! Att, André
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
