Entendi.O diretório para arquivar os logs poderia ser?pg_xlog/archive_statusAgradeço novamente>>> Me parece que sua rede por rádio é bem rápida.>> Sim, e uma solução Ubitiqui Full Duplex. (solução muito boa, com custo>> baixo.)>>> Perguntas:>>> Como está o archive_command do mestre?>> Não estou usando o archive_command, pois tavo vendo que na versão 9.0 não e>> mais necessário utilizar. Eu apenas defino estes 3 parametros no>> postgres.conf> > Como assim não é mais necessário utilizar? Onde é que leste isso?> O archive_command não é necessário pro streaming, mas ele ainda é> necessário para o backup! E também para servidores escravos que vão> muito atrás do mestre, o seu caso.> >> wal_level = hot_standby>> max_wal_senders = 1>> wal_keep_segments = 240> > Se você não faz archiving, você precisa de mais max_wal_senders. Isso> causa o erro que você está vendo. Incremente este valor. Durante> vacuum, a quantidade de dados modificadas é muito grande.> Se você fizesse archiving, mandando as cópias para o servidor escravo,> poderia não ter que se preocupar com isso, como o Euler já nos disse> aqui.> >>> Como está o recovery.conf do escravo? Mande pra nós se puder.>> standby_mode = 'on'>> primary_conninfo = 'host=192.168.1.253 port=5573 user=postgres>> password=SENHA'>> trigger_file = '/tmp/failover.trg'> > Se você tivesse archiving em algum lugar, poderia ter uma linha:> restore_command = 'cp /dir/archiving/%f %p'> ou> restore_command = 'scp IP.SERV.MESTRE:/dir/archiving/%f %p'> O erro que você vê não apareceria nunca mais.> >>> Como estão as permissões do diretório onde gravas o archive?>>Dentro o diretório pg_xlog tenho o diretório chamado archive_status onde>> não e gravado nada, nem no master e nem no slave cujo a permissão e ambos>> esta:>> drwx------ 2 postgres postgres> > Ok.> >>>> Já dentro do diretório pg_xlog posso muitos logs gerado pelo postgres,>> exemplo abaixo.>> 000000010000001000000070>> Estes foi criado no master e foi replicado para o slave, o mesmo acontece>> com algums outros.> > O erro que você está vendo significa que o servidor slave está> precisando do arquivo:> 1) ainda no mestre, conforme wal_keep_segments OU;> 2) no diretório de archiving, para recuperação via restore_command.> > A presença do arquivo no slave significa que o slave criou o arquivo> e, agora, precisa dos dados via streaming ou restore_command para> fazer um restart point.> Cheque se, na exata hora que o erro aparece, se o *mestre* ainda tem o> arquivo. Se não, ressincronize tudo e aumente wal_keep_segments.> Minha sugestão é usar archive_command mandando os logs pro escravo. No> mínimo, mantenha uma cópia no mestre acessível pelo escravo. É o que> tenho em todos os meus 9.0 em hot-standby (já são 5 em produção).> > []s> Flavio> _______________________________________________> pgbr-geral mailing list> pgbr-geral@listas.postgresql.org.br> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral>
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
