> > > Oi, boa tarde, tudo bem? > Opa, tudo ótimo e ai?
> wal_keep_segments - Fiz alguns testes com volume de dados e simulando >> situação que o "slave parou", e resolvi deixar o valor do >> wal_keep_segments meio alto para evitar uma perca de sincronismo.. qual o >> impacto disso? tem pessoas que dizem que só usa mais espaço em disco e etc, >> não tem impacto significativo no desempenho? >> > > Na pratica esse parametro[1] quer dizer quantos segmentos de WAL que o > postgresql irá manter. Isso previne que o slave fique sem os WALs > necessários para sincronizar. Quanto mais arquivos, mais espaço em disco > será ocupado. Note que se o banco não puder gerar arquivos na pasta do > pg_xlog ele vai parar. > > Recomendo que tu dê uma olhadinha nos replications slots[4] > Pelo que eu li na documentação que tu me passou e no blog do Michel [1], era exatamente isso que eu precisava. Com slots, ele faz o controle de armazenar os WALs que não foram replicados, sem a necessidade de configurar archive_command e etc, claro que existem situações que isso é necessário, mas para o meu que é um simples Master-Slave.. acredito que os slots já resolvem. [1] - http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/ >> archive_command - Algumas pessoas dizem que não é recomendável colocar um >> servidor em produção sem a devida configuração do archive_command e >> restore_command, alguém tem alguma história que me conversa que é >> necessário? >> > > archive_command é o quando a ser utilizando quando tu setar o wal_level > para archive e a cada criação de novo arquivo wal na pasta pg_xlog, o > banco efetua o arquivamento do wal anterior. Se tua fila > (wal_keep_segments) for grande o bastante, não é necessário utilizar ele, > mas quanto os servidores rodam em vários datacenters (multi-region) é comum > de combinar as duas soluções: usar o SR pra replicação, e quando a fila não > tiver os wal necessários, tentar importar os wal necessários. Isso pode ser > configurado no recovery.conf sem nenhum programa de terceiros. > > Detalhes sobre standby que utilizam arquivamento estão na doc[3]. > Acredito que com os slots não preciso usar archive_command e restore_command. hot_standby - Este tipo de replicação o PostgreSQL irá utilizar os dois >> servidores para consultas? >> > > hot_standby[2] é um nome que damos ao servidor standby que permite abrir o > banco em readonly. Seria possivel utiliza-lo para consultas, porém tens que > utilizar alguma solução de balanceamento para dividir a carga entre os > servidores. Balancear os servidores gera alguns desafios quanto a > sincronização dos dados . > > Vou dedicar um tempo para estudar mais a fundo o pgpool, mas de início balancear os servidores não é o foco. > Escrevi muita coisa na corrida. Espero ter ajudado. =) > Obrigado pelas dicas, meu ajudou a bastante em trocar umas idéias e ler mais a fundo a questão dos slots. <http://www.leosoft.com.br/coopcred>
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
