Em 30-04-2013 16:42, Eduardo Rodrigues escreveu:
Boa tarde pessoal,
tenho dois servidores utilzando o PostgreSQL 9.2.2 e CentOS 6.3, e o
recurso streaming replication habilitado. Esta funcionando normalmente,
mas quando executo o vacuum no servidor master o servidor slave acusa o
seguinte erro:
FATAL: could not receive data from WAL stream: FATAL: requested WAL
segment *"***arquivo **Write-Ahead Log**" *has already been removed
*** troquei o nome do arquivo WAL por arquivo Write-Ahead Log
hot_standby = on
max_standby_archive_delay = 21600s
max_standby_streaming_delay = 21600s
hot_standby_feedback = on
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
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
