Desculpe pelo "sem assunto".. acabei me esquecendo..
Vou ficar com a opção 1, aumentando o delay para talvez 2min..
acredito que seja suficiente para o meu caso, e sem causar efeitos na segurança
da replicação..
Obrigado
Att,
Tulio
>________________________________
> De: Flavio Henrique Araque Gurgel <[email protected]>
>Para: Tulio Santos <[email protected]>; Comunidade PostgreSQL
>Brasileira <[email protected]>
>Enviadas: Quarta-feira, 30 de Novembro de 2011 17:01
>Assunto: Cancelamento de consulta em escravo (era: sem assunto)
>
>> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
