Re: [pgbr-geral] Consideração replicação

2016-05-31 Por tôpico Luiz Carlos L. Nogueira Jr. 
valeu
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-31 Por tôpico Euler Taveira 
On 31-05-2016 10:10, Luiz Carlos L. Nogueira Jr. wrote:
> Outra dúvida simples. A replicação deixa os bancos "iguais" tanto
> fisicamente quanto logicamente?
> 
Caso o atraso seja zero, logicamente sim e fisicamente não (objetos
temporários e tabelas unlogged não são replicados).

> Por ex. A fragmentação de um lado não poderia ser diferente do outro?
> 
Com atraso zero, não. No entanto, como a maioria das replicações são
assíncronas, poderá haver mais inchaço no servidor principal se você
optar por um atraso máximo alto ou mesmo não cancelar consultas no
servidor secundário. Conflitos [1] sempre geram fragmentações diferentes
nos servidores.


[1]
https://www.postgresql.org/docs/9.6/static/hot-standby.html#HOT-STANDBY-CONFLICT


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-31 Por tôpico Fabrízio de Royes Mello 
On 31-05-2016 10:10, Luiz Carlos L. Nogueira Jr. wrote:
> Flávio,
> 
> Outra dúvida simples. A replicação deixa os bancos "iguais" tanto
> fisicamente quanto logicamente?
> 
> Por ex. A fragmentação de um lado não poderia ser diferente do outro?
> 

O slave da replicação nativa é um "clone físico" do master porque a
replicação é feita a nivel de páginas e não no nivel lógico (sql).

Portanto são exatamente iguais (nivel fisico e lógico) e a fragmentação
tb será a mesma visto que é uma réplica física.

Nesse tipo de replicação se vc tem objetos inchados e efetuar uma
manutenção no master para resolver isso, esta manutenção será
"replicada" para o slave.

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-31 Por tôpico Luiz Carlos L. Nogueira Jr. 
Flávio,

Outra dúvida simples. A replicação deixa os bancos "iguais" tanto
fisicamente quanto logicamente?

Por ex. A fragmentação de um lado não poderia ser diferente do outro?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Luiz Carlos L. Nogueira Jr. 
> Então uma boa prática seria ficar fazendo um rsync (fora do
> archive_command) dos wals sempre pro slave e os limpando de tempos em
> tempos pra não encher a partição do slave

Não entendi bem sua ideia mas normalmente o que se faz é o
archive_command que envia seus logs de transação para algum lugar que
seja, também, acessível pela réplica (ou standby, desculpe, não gosto de
chamar de escravo). E esse lugar, de quebra, é seu backup.

É essa mesma a idéia.

Valeu

Em 24 de maio de 2016 11:03, Flavio Henrique Araque Gurgel  escreveu:

> > Então o slave fica procurando o que precisa no master e caso não
> > encontre ele vai fazer o restore_command e procurar no seu próprio
> > pg_xlog, podendo voltar a pesquisar no master depois de algumas
> > atualizações automaticamente.
>
> Isso.
>
> > O slave controla tudo isso?
>
> Sim.
>
> > Então uma boa prática seria ficar fazendo um rsync (fora do
> > archive_command) dos wals sempre pro slave e os limpando de tempos em
> > tempos pra não encher a partição do slave
>
> Não entendi bem sua ideia mas normalmente o que se faz é o
> archive_command que envia seus logs de transação para algum lugar que
> seja, também, acessível pela réplica (ou standby, desculpe, não gosto de
> chamar de escravo). E esse lugar, de quebra, é seu backup.
>
> []s
> Flavio Gurgel
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Luiz Carlos L. Nogueira Jr. 
 Flávio,

> Por exemplo:
> > Se meu master cair mas eu tiver uma cópia dos archives em outro lugar,
> > colocando o restore_command ele vai buscar de lá. Seria uma opção de
> > contingência caso
> > o master caia
>
> Sim, e também se a réplica ficar muito atrasada em relação ao master.
>

Então o slave fica procurando o que precisa no master e caso não encontre
ele vai fazer o restore_command e procurar no seu próprio pg_xlog, podendo
voltar a pesquisar no master depois de algumas atualizações automaticamente.
O slave controla tudo isso?


Então uma boa prática seria ficar fazendo um rsync (fora do
archive_command) dos wals sempre pro slave e os limpando de tempos em
tempos pra não encher a partição do slave


Luiz carlos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Flavio Henrique Araque Gurgel 
> Então o slave fica procurando o que precisa no master e caso não
> encontre ele vai fazer o restore_command e procurar no seu próprio
> pg_xlog, podendo voltar a pesquisar no master depois de algumas
> atualizações automaticamente.

Isso.

> O slave controla tudo isso?

Sim.

> Então uma boa prática seria ficar fazendo um rsync (fora do
> archive_command) dos wals sempre pro slave e os limpando de tempos em
> tempos pra não encher a partição do slave

Não entendi bem sua ideia mas normalmente o que se faz é o
archive_command que envia seus logs de transação para algum lugar que
seja, também, acessível pela réplica (ou standby, desculpe, não gosto de
chamar de escravo). E esse lugar, de quebra, é seu backup.

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

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Flavio Henrique Araque Gurgel 
> 
> Por exemplo:
> Se meu master cair mas eu tiver uma cópia dos archives em outro lugar,
> colocando o restore_command ele vai buscar de lá. Seria uma opção de
> contingência caso
> o master caia

Sim, e também se a réplica ficar muito atrasada em relação ao master.

> Qual operação que fica startando o restore_command?

Se a conexão com o master falhar ou se a réplica estiver muito atrasada
(tipo, caiu e ficou muito tempo fora), o master responde que não tem
mais aquele arquivo que a réplica pediu e a réplica tem a opção de fazer
um restore_command pra recuperar o atraso.

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

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Luiz Carlos L. Nogueira Jr. 
>
> Flávio,
>


> 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.
>
>
Por exemplo:
Se meu master cair mas eu tiver uma cópia dos archives em outro lugar,
colocando o restore_command ele vai buscar de lá. Seria uma opção de
contingência caso
o master caia


Qual operação que fica startando o restore_command?

 Luiz carlos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Flavio Henrique Araque Gurgel 
> 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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-24 Por tôpico Luiz Carlos L. Nogueira Jr. 
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.

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?

Agora, uma dúvida. Se o slave virar um master automaticamente, a
configuração hot_standby=on não pode gerar algum problema?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Euler Taveira 
On 20-05-2016 12:12, Fabrízio de Royes Mello wrote:
> Não precisa fazer nada no slave pois quando o PostgreSQL está em standby
> ele não arquiva o wal. O worker do arquivamento é iniciado depois
> somente se for promovido, entao tanto faz a configuração que tenha nos
> parametros archive_*.
> 
Isso só é válido para archive_mode = on. A partir do 9.5, archive_mode =
always faz o arquivamento no slave também.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Fabrízio de Royes Mello 
On 20-05-2016 13:08, Matheus Ricardo Espanhol wrote:
> E apartir da 9.5 temos os Replication Slots e dai vc nem precisa se
> preocupar com archiving.
> 
> Att,
> 
> [1]
> 
> http://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION-SLOTS
> 
> 
> Bem lembrado Fabrizio. Mas vale o alerta que esta alternativa pode
> acumular xlogs no master indefinidamente  em caso de indisponibilidade
> do slave. 
> 

Certamente, por isso precisamos *sempre* monitorar nosso SGBD... e em
caso de indisponibilidade muito grande do slave remove-se o Replication
Slot e vida que segue.

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Matheus Ricardo Espanhol 
>
> E apartir da 9.5 temos os Replication Slots e dai vc nem precisa se
> preocupar com archiving.
>
> Att,
>
> [1]
>
> http://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION-SLOTS


Bem lembrado Fabrizio. Mas vale o alerta que esta alternativa pode acumular
xlogs no master indefinidamente  em caso de indisponibilidade do slave.

-- 
Matheus Ricardo Espanhol
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Fabrízio de Royes Mello 
On 20-05-2016 11:59, Matheus Ricardo Espanhol wrote:
> 
> 
> 2016-05-20 10:14 GMT-03:00 Luiz Carlos L. Nogueira Jr.
> >:
> 
> 
> Matheus,
> 
> A minha ideia é ter o master no modo archive, mas não sei das
> vantagens/desvantagens desse modo no slave.
> 
> 
> No slave não será necessário o modo archive.
>  

Não precisa fazer nada no slave pois quando o PostgreSQL está em standby
ele não arquiva o wal. O worker do arquivamento é iniciado depois
somente se for promovido, entao tanto faz a configuração que tenha nos
parametros archive_*.


[...]


> Se eu fizer em um ou em outro o archive_command do que não fizer
> será um comando qualquer que retorne true ou posso deixar null?
> 
> 
> Você pode manter o archive_mode habilitado e utilizar algo como 'exit 0'
> no slave. Isso é apenas para evitar um futuro restart caso queira voltar
> arquivar. Lembre-se que o arquivamento será feito pelo pg_receivexlog e
> é obrigatório para gerar o backup base.
> 

Como falei acima não precisa fazer nada em relação aos parametro
"archive_*" no slave.


[...]

> *--Mas, onde enfileirará caso  o master fique esperando o slave? Se
> no archive, os dados poderão, dependendo do tempo, estar no wal, mas
> se não tiver no archive mode, a replicação "morre" e terei de fazer
> tudo do 0 de novo?*
> 
> 
> Mesmo não estando no modo archive, a replicação streaming se sincroniza
> através do WAL. Portanto, você pode manter alguns xlogs com o parâmetro
> wal_keep_segments. Em um cenário onde você tem um backup PITR ativo
> (archive) você ainda pode contar com os xlogs salvos no servidor de
> backup para fazer o sincronismo quando o slave voltar.
> 
> Após o sincronismo através do WAL, o slave irá se conectar no master
> para iniciar a replicação.
>  

E apartir da 9.5 temos os Replication Slots e dai vc nem precisa se
preocupar com archiving.

Att,

[1]
http://www.postgresql.org/docs/9.5/static/warm-standby.html#STREAMING-REPLICATION-SLOTS

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Matheus Ricardo Espanhol 
2016-05-20 10:14 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

>
> Matheus,
>
> A minha ideia é ter o master no modo archive, mas não sei das
> vantagens/desvantagens desse modo no slave.
>

No slave não será necessário o modo archive.


> Qual seria a diferença/vantagens entre fazer o backup no master ou no
> slave?
>

Apenas a descentralização das operações evitando impactos no master (CPU,
rede, etc).  A desvantagem de "pendurar" backups no slave é que, ao ficar
indisponível, você pode gerar backups muito atrasados.


> Se eu fizer em um ou em outro o archive_command do que não fizer será um
> comando qualquer que retorne true ou posso deixar null?
>

Você pode manter o archive_mode habilitado e utilizar algo como 'exit 0' no
slave. Isso é apenas para evitar um futuro restart caso queira voltar
arquivar. Lembre-se que o arquivamento será feito pelo pg_receivexlog e é
obrigatório para gerar o backup base.


> *--isso fazendo o backup no master ou no slave? E o parâmetro é no master
> ou slave?*
>

Caso o pg_dump seja no slave. O parâmetro é no slave.

>
> *--não sabia dessa possibilidade. vou estudar, só conhecia do begin/end
> backup*
>
> 7- Se eu desligar o slave, o master ficará quanto tempo tentando mandar o
>> próximo comando pro slave? Isso geral alguma fila no master?
>>
>
> A conexão streaming será perdida, portanto o master não aguardará nada do
> Slave. Ele passará a considerar a replicação novamente após a solicitação
> da nova conexão pelo Slave.
>
> *--Mas, onde enfileirará caso  o master fique esperando o slave? Se no
> archive, os dados poderão, dependendo do tempo, estar no wal, mas se não
> tiver no archive mode, a replicação "morre" e terei de fazer tudo do 0 de
> novo?*
>

Mesmo não estando no modo archive, a replicação streaming se sincroniza
através do WAL. Portanto, você pode manter alguns xlogs com o parâmetro
wal_keep_segments. Em um cenário onde você tem um backup PITR ativo
(archive) você ainda pode contar com os xlogs salvos no servidor de backup
para fazer o sincronismo quando o slave voltar.

Após o sincronismo através do WAL, o slave irá se conectar no master para
iniciar a replicação.


>
>
> Agradecendo antecipadamente,
> Luiz Carlos
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Matheus Ricardo Espanhol
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-20 Por tôpico Luiz Carlos L. Nogueira Jr. 
Matheus,

A minha ideia é ter o master no modo archive, mas não sei das
vantagens/desvantagens desse modo no slave.
Qual seria a diferença/vantagens entre fazer o backup no master ou no
slave?
Se eu fizer em um ou em outro o archive_command do que não fizer será um
comando qualquer que retorne true ou posso deixar null?


2-Seria possível e vantajoso deixar os 2 no modo archive e fazer o backup
> no slave, mesmo com o "atraso" nos dados? O backup não escreve nada no
> banco? Se sim, não posso fazer no slave. Se não, como fica a situação, já
> que o slave ficará congelado entre o inicio e fim do backup?
>

Você pode fazer tanto o backup pg_dump quanto o backup incremental a partir
do slave.
pg_dump: O parâmetro max_standby_streaming_delay deve estar em -1, para que
o backup não seja cancelado pelo slave.

*--isso fazendo o backup no master ou no slave? E o parâmetro é no master
ou slave?*

backup PITR: Você pode utilizar o pg_basebackup para fazer o backup base e
o pg_receivexlog para fazer o incremental.

*--não sabia dessa possibilidade. vou estudar, só conhecia do begin/end
backup*

7- Se eu desligar o slave, o master ficará quanto tempo tentando mandar o
> próximo comando pro slave? Isso geral alguma fila no master?
>

A conexão streaming será perdida, portanto o master não aguardará nada do
Slave. Ele passará a considerar a replicação novamente após a solicitação
da nova conexão pelo Slave.

*--Mas, onde enfileirará caso  o master fique esperando o slave? Se no
archive, os dados poderão, dependendo do tempo, estar no wal, mas se não
tiver no archive mode, a replicação "morre" e terei de fazer tudo do 0 de
novo?*


Agradecendo antecipadamente,
Luiz Carlos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Consideração replicação

2016-05-19 Por tôpico Matheus Ricardo Espanhol 
Boa noite Luiz,

2016-05-19 22:30 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> Caros,
> Estou pretendendo fazer a replicação nativa do postgres e gostaria de
> saber algumas considerações
> O slave será utilizado apenas para consultas e não virará master
> automaticamente por motivos internos, i.e. não queremos (no momento) uma
> solução de HA.
> Diante disso:
> 1-Poderei deixar o slave em modo de noarchive, diferentemente do master?
>

Sim. A replicação Streaming é independente do archive, tecnicamente você
não precisa do arquivamento nem no master.


> 2-Seria possível e vantajoso deixar os 2 no modo archive e fazer o backup
> no slave, mesmo com o "atraso" nos dados? O backup não escreve nada no
> banco? Se sim, não posso fazer no slave. Se não, como fica a situação, já
> que o slave ficará congelado entre o inicio e fim do backup?
>

Você pode fazer tanto o backup pg_dump quanto o backup incremental a partir
do slave.
pg_dump: O parâmetro max_standby_streaming_delay deve estar em -1, para que
o backup não seja cancelado pelo slave.
backup PITR: Você pode utilizar o pg_basebackup para fazer o backup base e
o pg_receivexlog para fazer o incremental.


> 3-O tempo que o slave poderá ficar fora é o tempo de existência do wal
> segment no master? O que fazer pra maximizar esse tempo?
>

Aumentar o wal_keep_segments no master ou ativar o arquivamento no master
para fazer backup dos segmentos.


> 4-Os 2 bancos tem que estar na mesma versão majoritária ou não faz
> diferença?
>

É obrigatório estar na mesma versão maior.


> 5-Os pg_hbas terão de ser sincronizados via SO
>

Eles são copiados apenas no backup base inicial. Portanto, se deseja
garantir o sincronismo deverá ser via SO


> tem alguma maneira de acompanhar o atraso enter o master e o slave em
> numero de transações e/ou tempo?
>

Por  tempo:
SELECT CASE WHEN pg_last_xlog_receive_location() =
pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp()) END AS log_delay;


> 6-O que é mandado do master pro slave são as instruções (DMLs) ou os dados
> em si? Se for DMLs e os 2 servidores estiverem com horários diferentes não
> dará problema?
>

São os dados gravados no WAL.


> 7- Se eu desligar o slave, o master ficará quanto tempo tentando mandar o
> próximo comando pro slave? Isso geral alguma fila no master?
>

A conexão streaming será perdida, portanto o master não aguardará nada do
Slave. Ele passará a considerar a replicação novamente após a solicitação
da nova conexão pelo Slave.


>
>
> Valeu e boa noite
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Matheus Ricardo Espanhol
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral