2015-05-06 23:14 GMT-03:00 Edson F. Lidorio <[email protected]>:

> standby_mode=on
> primary_conninfo='host=192.168.0.100 user=replicador application_name=
> jessie-stby'
> trigger_file='/tmp/pgtrigger'
> restore_command = 'scp 192.168.0.100:/var/pg_archive/%f
> /var/lib/postgresql/9.4/main/"%p"'
>
> Só que estou com dúvidas no log de erros do servidor secundário:
>
> 2015-05-06 23:02:41 BRT [594-37] LOG:  arquivo de log restaurado
> "000000010000000100000028" do arquivador
> [...]
> 2015-05-06 23:02:52 BRT [594-44] LOG:  arquivo de log restaurado
> "00000001000000010000002F" do arquivador
> scp: /var/pg_archive/000000010000000100000030: No such file or directory
> 2015-05-06 23:02:55 BRT [1036-1] LOG:  iniciado fluxo de WAL do principal
> em 1/30000000 na linha do tempo 1
>
> É normal ele procurar esse arquivo e depois sincronizar novamente?
> scp: /var/pg_archive/000000010000000100000030: No such file or directory
>

Sim é normal, ele busca todos arquivos, até os que não existem, somente
quando o comando chamado pelo restore_command apresenta erro que o
PostgreSQL identifica que não tem ainda este arquivo disponível no
diretório, e então deixa de fazer "archive recovery" (definido pelo
restore_command) e conecta no primário para entrar em "streaming
replication" (definido pelo primary_conninfo), depois disso irá permanecer
em "streaming" o tempo todo. A não ser que perca a sincronia, então voltará
ao "archive recovery" até sincronizar todos os arquivos, quando essa mesma
mensagem aparecer, e iniciar "streaming replication" novamente, e assim por
diante.

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