> Boa tarde, Boa tarde Tulio, favor inserir um assunto no email sempre que perguntar algo na lista. Ajuda a manter a organização e buscas.
> Estou tentando executar uma consulta longa no servidor slave e está > apresentado erro > por entrar em conflito com a replicação... > ERROR: canceling statement due to conflict with recovery > DETAIL: User query might have needed to see row versions that must be > removed. > > no log.. > 2011-11-30 13:26:47 BRST [2299]: [5-1] user=usuario,db=atena LOG: temporary > file: path "base/pgsql_tmp/pgsql_tmp2299.0", size 407044096 > 2011-11-30 13:27:46 BRST [2299]: [6-1] user=usuario,db=atena ERROR: > canceling statement due to conflict with recovery > 2011-11-30 13:27:46 BRST [2299]: [7-1] user=usuario,db=atena DETAIL: User > query might have needed to see row versions that must be removed.p Isso pode realmente acontecer. > > Uso a versão 9.1... em Hot StandBy > Isso é comum em outras versões? A partir da 9.0, sim, é comum. > Alguem ja passou por isso? Sim. Isso acontece porque uma tupla necessária para a leitura da sua consulta no escravo foi limpa pelo (auto)vacuum do mestre. O mestre não tem como saber se uma página ainda é necessária para o escravo, então, ele limpa "cegamente" e isso é totalmente replicado. Você tem algumas alternativas: 1) No escravo, aumentar o valor de max_standby_streaming_delay. O padrão é 30 segundos. O PostgreSQL escravo faz então uma "pausa" na aplicação da replicação até que sua consulta termine. Esse tempo pode ser aumentado. Você pode colocar o valor 0 (zero) para que nenhuma consulta seja cancelada, mas uma consulta muito demorada pode pausar a aplicação da replicação e os dados lidos por outras consultas podem se tornar muito antigos. Se sua aplicação tolera isso, sem problemas, por exemplo, se você só faz consultas para alimentar um BI nesse escravo. 2) No mestre, configurar o valor de vacuum_defer_cleanup_age. Este valor padrão é zero, ou seja, após uma tupla ser "inútil" para o mestre, ela será limpa assim que o (auto)vacuum quiser. O valor aqui é em transações. Você pode colocar um valor alto de transações (que você precisa medir pra saber quantas) e então a rotina de limpeza "espera" que esse número de transações passe para fazer a limpeza e replicá-la. Nesta estratégia, haverá um aumento de consumode de espaço em disco tanto do mestre como do escravo, pois páginas que poderia já estar limpas ficarão disponíveis por mais tempo em disco. As consultas no escravo terão então um tempo maior de validade de tuplas disponíveis e mais dificilmente serão canceladas. Espero que ajude, este tópico é muito interessante. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
