Em 9 de dezembro de 2013 14:57, Eurides Baptistella <
[email protected]> escreveu:

> >> Certo Euler, mas neste caso eu teria que abandonar a replicação por
> Streaming?
> >>
> > Não.
>
> A ideia então é que quando a replicação por Streaming perder a
> sincronização, ela se recupere através dos arquivos de WAL previamente
> arquivados?
> Bastaria então que eu ajustasse no srv Slave:
> [recovery.conf]
> standby_mode='on'
> primary_conninfo='host=xxx.xxx.xx.xx port=xxxx user=xxxx password=xxxx'
> trigger_file='/tmp/pgs_trg_replication.pgsql'
> restore_command = 'cp /mnt/server/archivedir/%f %p'
>
> E em meu srv Master:
> [postgresql.conf]
> archive_mode = on
> archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p
> /mnt/server/archivedir/%f'
>
> Isso seria suficiente para que quando a replicação Streaming perder o
> sincronismo consiga se recuperar através dos arquivos de WAL?
>

Pra tu não ficar perdido, eu mesmo respondo.. hehehe
Sim! Exatamente. É possível verificar isso no próprio status de
inicialização do server slave.
Para testar, caso esteja usando replicação (a)ssíncrona, basta você, após
configurar os comandos de archive e restore, realizar diversas operações no
master com o slave parado. Depois disso, quando iniciar o slave, você verá
que ele irá realizar os comandos de restore durante a inicialização, após
ver que o arquivo checkpoint está diferente do master.


>
> Após a utilização dos arquivos de WAL para se recuperar, ele volta a
> utilizar o Streaming?
>

Exatamente. Após isso, ele próprio identifica qual o arquivo de checkpoint
"corrente" e prossegue o recebimento da replicação por streaming.

Espero ter ajudado..

[]'s


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

Responder a