Muito interessante Matheus ! Creio então que seja a segunda opção, que existe o arquivo. Segue abaixo os procedimentos que faço:
-- Gero um cluster postgresql (initdb) -- Realizo configurações nos arquivos pg_hba.conf (usuário replication) e postgresql.conf (habilitar wal, tipo de arquivamento, path) -- Dou restart no postgresql -- Crio um banco novo com uma tabela apenas -- Alimento a tabela com total de 535899 (psql -U postgresq -d banco -f dados.sql) -- Logo em seguida executo o pg_basebackup sem o -x (pg_basebackup -U replicador -h IP -D basebackupI/ -Ft -z -P) -- alimento novamente com dados, mais 535899 registros -- Dou um stop no postgresql -- Deleto tudo do $PGDATA/ descompacto o base.tar.gz e crio o recovery.conf -- Dou um start no banco Sistematizei alguns passos para estudo do PITR através de um script shell que realiza alguns procedimentos que descrevo acima. Então logo após a carga de dados ja executo em seguida o pg_basebackup. As vezes quando faço esse procedimento muito rápido o pg_basebackup fica aguardando um pouco pra depois começar a gerar o base.tar.gz. Bem foi dessa forma que consegui bolar um jeito para gerar arquivos wal e realizar testes de restore. Em 24 de agosto de 2015 11:03, Matheus de Oliveira < [email protected]> escreveu: > > 2015-08-21 19:47 GMT-03:00 Franklin Anderson de Oliveira Souza < > [email protected]>: > >> Tenho me dedicado a estudar o PITR, realizando vários tipos de testes. Em >> um exemplo simples, alimento um banco com dados para gerar arquivos WALs, >> em seguida crio um backup fisico com pg_basebackup e volto alimentar com >> mais dados. Feito isso dou stop no banco, deleto tudo do PGDATA, >> descompacto o base.tar.gz criado pelo pg_basebackup e crio o arquivo >> restore.conf, dou start no banco e tudo volta funcionar normalmente, pois >> posso ver os últimos dados inseridos da ultima carga de dados. Mas no log >> tenho a seguinte mensagem que gostaria que vocês me explicassem o que pode >> ser, segue abaixo: >> >> DETAIL: The failed archive command was: test ! -f >> /backup/postgresql/archive/00000001000000000000000C && cp >> pg_xlog/00000001000000000000000C >> /backup/postgresql/archive/00000001000000000000000C >> LOG: archive command failed with exit code 1 >> > > Pelo jeito é o "test" que está falhando, se o cp estivesse falhando você > veria uma mensagem de erro emitida pelo mesmo (a não ser que tenha removido > a mesma no e-mail). O que significa então que o arquivo > 00000001000000000000000C já deve ter sido arquivado anteriormente. Pode > verificar se o arquivo está lá? > > Se o arquivo estiver lá, então creio que aconteceu o seguinte: > > 1. O 00000001000000000000000C não estava arquivado ainda quando fez o > backup do servidor primário > 2. Você fez um backup incluindo o pg_xlog (e.g. -x ou -X no > pg_basebackup), certo? > 3. Ao restaurar o backup e iniciar o novo servidor, o PostgreSQL verificou > (pela archive_status) que esse segmento não tinha sido arquivado, e tentou > fazer o arquivamento. Mas, como este foi arquivado *após* o backup, esse > erro foi apresentado. > > Assumindo que estou certo acima. Ainda temos uma questão. O pg_basebackup, > em teoria, devia esperar o arquivamento de todos os segmentos necessários > antes de terminar. O que não causaria essa situação, pode passar o > procedimento que executou tanto no backup como na restauração? > > Estou assumindo outra coisa, que o timeline após a restauração foi > alterado (para 2, provavelmente); nesse caso o arquivo > 00000001000000000000000C não foi gerado por esse novo servidor. Isso está > correto? > > Atenciosamente, > -- > Matheus de Oliveira > > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- foobar
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
