Bom dia pessoal, peguei as dicas que o Euler passou, e executei novamente o
processo para replicação. fiz a cópia com rsync, mas antes disto fiz a
atualização S.O. nos servidores e deixei os dois iguais nas suas versões do
postgres e por enquanto a replicação está funcionando normalmente, mas como
isso também ocorria antes, estou monitorando constantemente os servidores
para verificar se continua a replicação. No entanto, sobre o
restore_command, dei uma procurada e não consegui encontrar um material que
explicasse exatamente como tenho que montar o arquivo recovery.conf
utilizando o restore_command, ví em vários materiais muita coisa mas nenhum
explicando detalhado como faz.
Pelo que entendi o restore_command é executado caso os servidores percam o
sincronismo.

Se vocês tiverem um material que eu possa utilizar para montar esse arquivo.

Desde já obrigado pela ajuda.

Diógenes V. Bittencourt

Em 10 de maio de 2016 16:09, Euler Taveira <[email protected]> escreveu:

> On 10-05-2016 14:00, Diógenes Vargas de Bittencourt wrote:
> > *Configurações de hardware das máquinas:
> > *
> > *MASTER
> > */Operating system    Ubuntu Linux 14.04.3
> > Processor information    Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz, 24
> cores
> > Real memory    7.77 GB used, 47.05 GB total
> > Postgres 9.3.10/*
> > *
> Atualize o PostgreSQL.
>
> > *SLAVE
> > */Operating system    Ubuntu Linux 14.04.4
> > Processor information    Intel(R) Xeon(R) CPU E5530 @ 2.40GHz, 16 cores
> > Real memory    1.03 GB used, 23.53 GB total
> > Postgres 9.3.12/*
> > *
> > *
> > Segue arquivo de configuração do master:*
> >
> É necessário "garimpar" o log para saber o porquê da perda de
> sincronismo mas pela sua configuração há duas causas possíveis:
>
> (i) alguma consulta no slave "segurou" a replicação e durante esse
> período o servidor principal reciclou um arquivo de WAL que seria
> necessário no servidor secundário;
> (ii) wal_keep_segments não é suficiente para uma carga de dados. Pode
> ocorrer que wal_keep_segments (juntamente com checkpoint_segments) não
> seja suficiente durante uma carga de dados fazendo com que o servidor
> principal recicle arquivos que são necessários no servidor secundário.
>
> Para evitar esses problemas, faça arquivamento do WAL e use o
> restore_command no recovery.conf. Assim, se faltar um arquivo por um dos
> dois motivos o servidor secundário buscará no repositório contendo os
> arquivos de log arquivados.
>
>
> --
>    Euler Taveira                   Timbira - http://www.timbira.com.br/
>    PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> _______________________________________________
> 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