> Agora que eu entendi a idéia da replicação... :)
> 
> O slave, através da configuração do primary_conninfo do recovery.conf e
> dos status de hot_standby=on, vai no server e pega os dados necessário
> dos wals.

Isso.
E você pode colocar um restore_command se quiser restaurar também a
partir de um backup que contenha os arquivos WAL.
O PostgreSQL passa automaticamente de um modo para o outro, priorizando
a conexão com o master.

> Minha idéia anterior era que o server que ficava mandando pro slave.
> 
> Nessa estrutura o server pode ficar desligado muito tempo que não
> perdemos a replicação, mas no caso do slave ele pode ficar desligado o
> tempo em que ainda existirem os wal no master que ele consiga manter a
> sequencia de sincronia, por isso devemos deixar alto
> o  wal_keep_segments (dar tempo maior para fazer alguma manutenção no
> slave).
> 
> É isso mesmo?

Isso mesmo.
Ou, como eu disse, você pode setar um restore_command.
A partir da versão 9.5 você tem os replication slots, que gerenciam a
guarda de logs de transação pra você no master, diminuindo a necessidade
de restore_command em todas as réplicas.

> Agora, uma dúvida. Se o slave virar um master automaticamente, a
> configuração hot_standby=on não pode gerar algum problema?

Esta configuração é ignorada quando o servidor é master.

[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a