Em 26 de novembro de 2015 10:37, Lucas Viecelli <[email protected]>
escreveu:
Oi, boa tarde, tudo bem?
> PostgreSQL 9.4, ubuntu-server 15.10
>
> Estou estudando replicação hot_standby do PostgreSQL, configurei um
> mestre-slave. Tudo funcionou normalmente, mas ainda tenho algumas dúvidas,
> espero que alguém possa me ajudar.
>
> 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]
>
> 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].
>
> pg_start_backup - Se o meu servidor Slave perder o sincronismo eu devo
> executar um "select pg_start_backup('foo');" para o servidor
> do PostgreSQL se preparar para replicar os dados pro slave, e após isso um
> "stop", com isso eu posso replicar o BD e deixar ele online, isso está
> correto? pelo que estudei até agora, essa é a melhor forma de fazer o
> slave recuperar os dados perdidos.
>
Se tem slave não tenha os WALs necessários para importar do master e também
não tenha os wals arquivados, tu vai ter que fazer a copia dos dados
novamente seja através do pg_basebackup ou do processo manual
(pg_start_backup ; copia ; pg_stop_backup). Não tem jeito. mesmo.
>
> 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 .
Escrevi muita coisa na corrida. Espero ter ajudado. =)
[1]
http://www.postgresql.org/docs/current/static/runtime-config-replication.html
[2] http://www.postgresql.org/docs/9.4/static/hot-standby.html
[3] http://www.postgresql.org/docs/9.4/static/warm-standby.html
[4]
http://www.postgresql.org/docs/9.4/static/warm-standby.html#STREAMING-REPLICATION-SLOTS
--
Sebastian Webber
http://swebber.me
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
