> Acabei de realizar os testes baseados nas suas dicas e nas do Flávio e a
> replicação esta quase 100%. Estou com uma última dificuldade no master e uma
> dúvida no Slave.
> [MASTER]
> Depois de enviar alguns logfiles, eu tive de reiniciar o master para aplicar
> outras configurações não relacionadas. Aproveitando o restart, eu apaguei
> alguns arquivos da pasta pg_xlog, anteriores a execução do tarball, mas que
> ainda não haviam sido enviados. Eu apaguei eles simplesmente para que não
> gastasse tempo enviando arquivos inúteis, uma vez que só me interessa o
> envio dos arquivos gerados após a geração do tarball.
> Após iniciar o master novamente, reparei que ele não está mais enviando os
> arquivos, embora novos tenham sido gerados. Precisamente ao mandar master
> reiniciar novamente ele começa a enviar mais um arquivo. Esse comportamento
> não foi coincidência: se repetiu por 5 vezes. Só envia um arquivo quando
> mando reiniciar o servidor. O que pode estar causando isso?
Os arquivos deveriam ser enviados quando finalizados, durante o
movimento transacional normal de escrita no seu banco de dados.
Não existe relação entre o reinício do servidor. Você pode forçar a
finalização com o comando (como usuário administrador):
SELECT pg_switch_xlog();
Outros motivos para envio imediato são forçar um ponto de controle, o
último arquivo aberto será finalizado forçosamente:
CHECKPOINT;
Ou iniciando um backup, que força um ponto de controle e a finalização
do último arquivo aberto:
SELECT pg_start_backup('nome do seu backup');
Na hora do reinício um arquivo que estava pendente de envio e que
ainda não foi completamente enviado antes da parada do PostgreSQL por
falta de banda de rede pode forçar o envio na hora do início.
> [SLAVE]
> O Slave está floodando o log com a seguinte mensagem:
> cp: cannot stat `/home/postgresql/remote_logs/000000010000000000000043': No
> such file or directory
Isso é normal. Ele está esperando o próximo cara chegar. Note que é um
"warning" e não erro.
>
> Existe algum parâmetro para alterar a frequencia com a qual o
> restore_command tenta ser executada ou o negócio é colocar o '&& sleep 30'
> no comando?
Eu não colocaria o sleep. Não precisa.
> Posso suprimir a mensagem de erro com um 2> /dev/null no comando ou isso não
> seria saudável, caso precise debugar um problema?
Você não deve fazer isso pois o PostgreSQL precisa saber o resultado
do comando. Enquanto ele não retornar 0 o PostgreSQL permanece
tentando. Se você redirecionar a saída pode causar confusão. A
mensagem em log é saudável, não se preocupe.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
