Tulio,

Para amenizar seu problema, posso sugerir um backup a quente. Funciona na
versao 9.1 .

O comando abaixo, que deverá ser rodado na maquina 2, faz um backup
completo da maquina1 que deverá estar online,  Dessa forma, você não terá
problemas com o seu ambiente.



O que tem que ser feito antes.
Na maquina 2, você deverá esvaziar todos os dados,  mantendo apenas o
diretorio totalmente vazio e as permissoes necessarias a ele, para o
postgres.

No meu caso, em linux, mantive:

/meupostgres/dados   ( permissão linux para o diretorio dados -> chmod 0700
)

se o seu diretorio de logs ficar dentro do meupostgres, não esqueça de
criá-lo e mudar o dono para o usuário postgres, isso não afetará a
transferência dos dados, mas você terá problemas para levantar o postgres
depois.

não se esqueça de copiar o seu recovery.conf para o diretorio
/meupostgres/dados , após a transferencia.

A transferência é super rápida, mas é claro, depende da rede entre as 2
maquinas.

Vamos a linha de comando:

- A transferencia deverá ser feita pelo usuario postgres
.banco1, a servidora master, que deverá online
.porta, porta da sevidora master
. -D , o diretorio da servidora local. É claro que ela está parada.

Não se preocupe com os archives. Ela deixará tudo pronto com o sincronismo.

Agora, antes de levantar o banco transferido, confira mais uma vez se você
colocou o recovery.conf no diretório de dados.

Levante o postgres e ela estará totalmente sincronizada.

Espero ter ajudado. Se tiver dúvidas, tentarei ajudar.

Abraço.



/usr/lib/postgresql/9.1/bin/pg_basebackup  -h banco1 -p 5600 -x
-D /meupostgres/dados -P -v


Em 8 de março de 2012 16:40, Tulio Santos <[email protected]>escreveu:

> 1) Vc faz arquivamento dos XLOG no master?
> Sim, mas apenas do Master diretamente no Slave.. e por conta do periodo
> inativo acabei por perder-los.
>
> 2) Que mensagem aparece no log do slave ao iniciá-lo?
> Observando agora, ele esta procurando arquivos de segmentos que não
> existem...
>
> Estou pensando nessa solução:
> 1- gerar um dumpall no master..
>     2- dropar bases do slave.. (sem estar ligado ao master)
>         3- restaurar no slave...
>             4- ressincronizar..
>
> Se tiverem uma outra ideia.. to aceitando.
>
> Att,
> Tulio
>
>   ------------------------------
> *De:* Fabrízio de Royes Mello <[email protected]>
> *Para:* Comunidade PostgreSQL Brasileira <
> [email protected]>
> *Enviadas:* Quinta-feira, 8 de Março de 2012 13:13
> *Assunto:* Re: [pgbr-geral] Nome de DB alterado durante replicação "off"
>
>
> Em 8 de março de 2012 12:23, Tulio Santos <[email protected]>escreveu:
>
> Bom dia pessoal,
>
> Tenho dois servidores trabalhando em replicação streaming.
> A slave esteve inativa durante um curto periodo (aprox. 1 dia), porem,
> neste periodo o nome de uma das bases foi alterado.
> Como a replicação entenderá esta situação?
> O OID da base foi alterado ao modificar o nome, certo?
> A slave saberá identificar a qual base deverá se referir?
>
>
> Duas perguntas:
>
> 1) Vc faz arquivamento dos XLOG no master?
>
> 2) Que mensagem aparece no log do slave ao iniciá-lo?
>
> Att,
>
> --
> Fabrízio de Royes Mello
> Consultoria/Coaching PostgreSQL
> >> Blog sobre TI: http://fabriziomello.blogspot.com
> >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
> >> Twitter: http://twitter.com/fabriziomello
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a