Primeiramente agradeço a todos.> Em 13 de maio de 2011 12:15, JotaComm <[email protected]> escreveu:>> Opa,>>> A replicação já estava funcionando?>>> A replicação funciona 100%, desde que não execute o vaccum no banco de>>> dados de 20 GB> > Tenho aqui autovacuum ligado e replicação por streaming funcionando a 100%.> Nunca tentei vacuum manualmente, mas o conceito é o mesmo.> >>> >> Após o retorno deste backup no servidor de replicação master enviei o>>> >> data conforme seu material para o servidor slave.>>> > Qual o procedimento realizado? Somente rsync ou pg_start_backup > rsync>>> > >>>> > pg_stop_backup?>>> Testei fazendo o backup online e ofline porem usei o rsync com scp>>>>>>>>>>>> Estou baixando a versão 9.0.2 do postgres para ver se não e um bug da>>> 9.0.4.> > Aqui é 9.0.4. Funciona como manteiga.> >>> Pelo que entendi o que esta ocorrendo e porque ele esta removendo um>>> determinado arquivo do pg_xlog do pricipal e não no slave, ai onde ocorre o>>> erro.>>> Tentei seguir uma sugestão do Matheus tambem atrazar a sicronização no>>> servidor slave com o parametro max_standby_streaming_delay = 0s>>> Porem sem sucesso na versão 9.0.4.> > Isso só é necessário quando uma consulta é cancelada no escravo por> causa de páginas já removidas, não pra evitar o erro que você está> citando.> >>> > Há alguma mensagem adicional no log a não ser dizendo que o arquivo do>>> > WAL não>>> > foi encontrado?Não só a mensagem mostrando o nome do arquivo informando que não foi removido.LOG: streaming replication successfully connected to primaryFATAL: could not receive data from WAL stream: FATAL: segmento do WAL solicitado 00000001000000080000001C já foi removido> > A única vez que vi isso acontecer foi quando o escravo ficou *muito*> mas *muito mesmo* atrás do mestre.Bom este servidor slave esta fora do prédio, esta em uma rede interligada via radio (A velocidade do radio da 30 MB/s), talvez pode ser isto?Testei com o banco de dados pequeno de 200 MB/s e funciona normalmente, já com o banco grande a coisa complica.> Como está seu arquivo recovery.conf? Poste aqui pra nós. standby_mode = 'on'primary_conninfo = 'host=192.168.1.253 port=5573 user=postgres password=K@lif@1'trigger_file = '/tmp/failover.trg'> Você tem> cópia dos logs de transação arquivados?> Seu archive_command está como?o valor do archive_command que esta dentro do postgres.conf esta default, comentado e sem valor#archive_command = ''Estou seguindo este material do Euler.Minhas conf estão iguais.http://eulerto.blogspot.com/2010/11/hot-standby-e-streaming-replication.html> >>> > Você tentou fazer o procedimento com o servidor principal em atividade,>>> > ou>>> > seja, utilizando pg_start_backup > rsync > pg_stop_backup?>>> >>>> > Você lembrou de listar os arquivos do WAL do servidor principal após>>> > concluir>>> > o passo de cópia (após o rsync ou pg_stop_backup -- dependendo do>>> > procedimento>>> > de cópia)? O arquivo solicitado existia?> > Complementando o Euler, você está guardando o arquivo aonde? O> restore_command aponta pro lugar certo?> Esses arquivos serão necessários se o escravo estiver muito atrás do mestre.> > []s> > Flavio Gurgel> _______________________________________________
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
