>> 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
