Em 30 de abril de 2013 16:56, <[email protected]>escreveu:
> Alguma consulta sua estava sendo cancelada no escravo? > Por que você precisa de 21600 segundos de delay máximo? Diminua este > valor ou você pode ter um escravo até 21600 segundos atrasado em relação > ao mestre. > > > sendo que no servidor master esta o recurso wal_keep_segments= 10000, ou > > seja, são utilizados até 160GB com os arquivos de log transacional. > > A não ser que seja um vacuum sobre uma tabela com mais de 160GiB de > tuplas mortas, você não deveria estar tendo o problema que apareceu no log. > > > Alguém sabe me informar se ha algum recurso que posso ativar nos > > servidores para não utilizar tanto espaço em disco do servidor master? > > Diminua max_standby_*_delay para um valor mais razoável, da ordem de no > máximo 5 ou 10 minutos e se realmente você estiver com consultas muito > lentas no escravo sendo canceladas. > > Depois, diminua wal_keep_segments para o equivalente a um ou dois > checkpoints (veja o valor que você pôs em checkpoint_segments e > multiplique por dois). > > []s > > __________________________________ > Flavio Henrique A. Gurgel > Líder de Projetos Especiais > Consultoria, Projetos & Treinamentos 4LINUX > Tel1: +55-11.2125-4747 ou 2125-4748 > www.4linux.com.br > email: [email protected] > ______________________________ > FREE SOFTWARE SOLUTIONS > Boa Tarde Flavio, obrigado por responder, sempre que executo o vacuum o servidor slave acusa o erro de que o arquivo do que ele necessita do pg_xlog ja foi removido. Pensando nesse erro então habilitei um tempo alto de atraso suficiente para o servidor Slave pudesse consumir o arquivo, mas não deu certo. Ainda não esta tendo consultas no servidor slave, portanto irei diminuir os recursos de delay, ou ate mesmo desabilitar. checkpoint_segments esta desabilitado, portanto irei realizar duas tarefas: 1a. analisa as tuplas mortas (pesquisar); 2a. habilitar o checkpoint_segments. Após realizar essas teredas irei responder o tópico com a solução. Obrigado pela ajuda Flavio
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
