Re: [pgbr-geral] Replicação multi master BDR / Bucardo

[Daniel Luiz da Silva]

Bom dia, 
Murilo, 

Caso alguém tenha auxiliado com tópico, gostaria que repasse para mim também, 
porque isso é um assunto de meu interesse. 
Agradeço sua pergunta. 

Att. 


De: "Murilo Habermann Torquato"  
Para: "Comunidade PostgreSQL Brasileira"  
Enviadas: Quarta-feira, 20 de abril de 2016 21:22:58 
Assunto: [pgbr-geral] Replicação multi master BDR / Bucardo 

Boa noite, 
Estou em um projeto onde surgiu a necessidade de utilização da replicação multi 
master em função da localização e de problemas de conectividade das unidades 
envolvidas na operação. 

Analisando as soluções, realizamos dois testes em laboratório com o Bucardo e 
por ultimo com o BDR. 

Aparentemente está OK nas tarefas básicas, mas minha pergunta/necessidade é: 

alguém com casos reais de uso destas ferramentas, tem algum tipo de experiência 
para compartilhar? 

Pesquisei na lista, e reparei que existem varias threads relacionadas, mas como 
preciso de serviços profissionais, abri um novo tópico para deixar meu contato, 
caso alguem se interesse para estarmos conversando. 

obrigado! 
-- 

http://www.devcoffee.com.br 

Murilo H. Torquato / Diretor Técnico 
devCoffee Business Solutions 

muril...@devcoffee.com.br / (19) 993 247 735 

Telefones: 
(19) 3555 2618 || (19) 3554 4031 || (11) 3522 3038 

Endereço: 
Rua Paulo Rebessi, 665 - Cidade Jardim 
CEP: 13614-260 - Leme / SP 






___ 
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] Replicação Multi-Master

[Flavio Henrique Araque Gurgel]

 Entre PgPool e Bucardo, qual o indicado?

Depende do que você quer fazer.
Ao invés de discutirmos as ferramentas, antes disso seria melhor você
explicar qual a sua idéia. O que você precisa.

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

Re: [pgbr-geral] Replicação Multi-Master

[Bruno Silva]

Eu preciso de Master/Master e balanceamento.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Fábio Telles Rodriguez]

Em 22 de julho de 2011 13:25, Bruno Silva bemanuel...@gmail.com escreveu:

 Eu preciso de Master/Master e balanceamento.


Ah... todo mundo quer isso... mas ninguém encontra exatamente o que procura.

Não tem resposta fácil para isso, mas um monte de gente já discutiu um pouco
desse assunto.

Minha opinião está em:
http://www.midstorm.org/~telles/2009/07/06/a-lenda-da-replicacao-multimaster-sincrona-em-bases-distribuidas/

-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http://www.midstorm.org/~telles/
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Diogo Borsoi]

Flavio,

Preciso de Master/Master, onde os servidores estão em redes e locais
geograficamente distintos.


Att.


-- 
=
Diogo Borsoi
=




2011/7/22 Flavio Henrique Araque Gurgel fha...@gmail.com:
 Entre PgPool e Bucardo, qual o indicado?

 Depende do que você quer fazer.
 Ao invés de discutirmos as ferramentas, antes disso seria melhor você
 explicar qual a sua idéia. O que você precisa.

 []s
 Flavio
 ___
 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] Replicação Multi-Master

[Flavio Henrique Araque Gurgel]

 Preciso de Master/Master, onde os servidores estão em redes e locais
 geograficamente distintos.

O ideal neste caso é usar um cara como o Bucardo e o Rubyrep,
master-master assíncronos.
Mas eles têm um implicações, você tem que cuidar com conflitos. Ambos
funcionam bem, o Rubyrep é mais fácil de configurar, o Bucardo é mais
estável.

Conheça-os:
www.rubyrep.org
bucardo.org

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

Re: [pgbr-geral] Replicação Multi-Master

[Diogo Borsoi]

Flávio,

Obrigado pelas informações.
Em 22/07/2011 17:40, Flavio Henrique Araque Gurgel fha...@gmail.com
escreveu:
 Preciso de Master/Master, onde os servidores estão em redes e locais
 geograficamente distintos.

 O ideal neste caso é usar um cara como o Bucardo e o Rubyrep,
 master-master assíncronos.
 Mas eles têm um implicações, você tem que cuidar com conflitos. Ambos
 funcionam bem, o Rubyrep é mais fácil de configurar, o Bucardo é mais
 estável.

 Conheça-os:
 www.rubyrep.org
 bucardo.org

 []s
 Flavio
 ___
 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] Replicação Multi-Master

[Flavio Henrique Araque Gurgel]

 Nas minhas pesquisas vi pessoas falando do Postgres-XC¹.
 Achei interessante pois, aparentemente, ele não é um middleware como o
 PgPool. É transparente.
 Então vem a minha dúvida, alguém já o utilizou? É viável?
 Site do projeto: http://postgres-xc.sourceforge.net/

A idéia é fantástica e é utilizada por outros caras como o DB2.
É viável sim, mas a implementação é complexa e está tomando muito
tempo de desenvolvimento e dinheiro.
EnterpriseDB e NTT são mentores do projeto.
Um dos responsáveis por isso estará no PGBR 2011 e palestrará sobre ele.
O projeto ainda está em estágio alpha e muitas funcionalidades estão
faltando, inclusive relacionadas a backup e replicação.
Se você tiver hardware adequado e puder utilizá-lo para testes poderá
ajudar no desenvolvimento.

[]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] Replicação Multi-Master

[Bruno Silva]

Estou estudando para colocar em produção.
Já confirmaram a grade do PGBR 2011?
Flávio no PGBR vocês só irão atravessar a rua neh? :D
Bruno E. A. Silva.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Flavio Henrique Araque Gurgel]

 Estou estudando para colocar em produção.

Eu não colocaria software alpha ou beta em produção, a não ser que
você tenha um ambiente de produção que possa estar sujeito a falhas,
paradas e perdas de dados.

 Já confirmaram a grade do PGBR 2011?

Ainda não, o CFP deve sair em breve.

 Flávio no PGBR vocês só irão atravessar a rua neh? :D

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

Re: [pgbr-geral] Replicação Multi-Master

[Bruno Silva]

É, então voltando para pgpool mesmo.
Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Mestrando em Ciências da Computação
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA
Novell DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!



2011/7/21 Flavio Henrique Araque Gurgel fha...@gmail.com

  Estou estudando para colocar em produção.

 Eu não colocaria software alpha ou beta em produção, a não ser que
 você tenha um ambiente de produção que possa estar sujeito a falhas,
 paradas e perdas de dados.

  Já confirmaram a grade do PGBR 2011?

 Ainda não, o CFP deve sair em breve.

  Flávio no PGBR vocês só irão atravessar a rua neh? :D

 Yup :)
 ___
 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] Replicação Multi-Master

[Bruno Silva]

Fiquei tão cego que não notei que o XC ainda estava em desenvolvimento.
Valeu Flávio.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Marcos - GMail]

 Buenas pessoal, na minha humilde idéia e tendo como experiência
própria a questão sincronismo, hoje usamos soluções próprias na empresa,
claro, respeitando nossa estrutura de banco de dados e não algo genérico. Em
muitos de nossos clientes, mantivemos sim os bancos iguais. Ainda não
tivemos a coragem de ter um banco centralizado, pois acreditamos que não
possuimos infra pra isto, e também, os clientes, não querem pagar por um
serviço especializado, mesmo sendo empresas de porte grande. Pensar em um
banco localizado na web ou servidor em um local com acessos por vpns, ainda
ferem a performace dos sistemas, dando ao cliente algo lento e muitas vezes
duvidoso.
Em cada tabela nossa, criamos um identificador, juntando
informações que fisicamente fazem que o registro seja endereçado, ou seja os
movimentos de uma empresa vai para outra, mas, ficam dentro do banco/tabela
separada como se as empresas estivesse fisicamente no mesmo local. Algumas
tabelas, como cliente são unicas, os registros vão de um lado para o outro,
respeitando o estado a ser processado, insert ou update somente. Não foi uma
coisa dificil de fazer é mais complicado de se manter e lembrar que temos
que manter e criar as trigger cada vez que nova tabela é incluída no banco,
mas esta dando certo a muito tempo.

Marcos André G.A
Trabin Softwarre  Consulting



Em 9 de julho de 2010 10:09, Alexsandro Haag
alexsandro.h...@gmail.comescreveu:

 Sinceramente não vejo problema nas características informadas pelo
 Alexsander.

 On 08-07-2010 20:51, fabi...@wolaksistemas.com.br wrote:
  Treços do teu email:
 
  Há tabelas globais onde apenas um servidor pode gravar - Se esse
  servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a
  aplicação em um data center, ou seja se você depende de um central não há
  porque ter as locais afinal não vai funcionar sem as globais não é?
 Ou
  entendi errado?
 
 Vejo que a diferença é que há um ponto central, porém este é replicado
 para as pontas. Com isso se o ponto central estiver indisponível as
 pontas continuam funcionando.
  Meu ERP usa um framework de persistência - Opção de cada desenvolver,
 eu
  por experiência recomendo passar longe desse tipo de coisa. Tomara que
 não
  acontece com você mas o dia que resolver dar pau, reze.
 
 Hoje os frameworks de persistência estão muito maduros e trazem
 produtividade, além de permitir uma boa independência de banco de dados.
 Pessoalmente defendo o seu uso, principalmente em grandes projetos, como
 ERPs, CRMs e afins. Mas acho perigoso tentar atender mais que 2 bancos.
 Acaba deixando tudo muito complexo de manter com o tempo.
  grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE -
  Já citado antes a questão da integridade, mas como você falou dependendo
  do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista.
  Hoje já temos infra suficiente para manter um link decente e se a
 desculpa
  for a rede que pode cair, vide a NFe e o SPED.
 
  um processo que roda no CRON das lojas envia estes comandos para o
  servidor central - No meu ponto de vista não é uma solução elegante.
 
 
 Aqui concordo com o Fabiano, pois os bancos de dados já provém soluções
 para replicação. Alguns até mais de uma, como é o caso do Postgres.

  O servidor central, por sua vez, envia para todas as lojas todas as
  atualizações que recebeu, também minuto a minuto. - Você centraliza,
  distribui e centraliza novamente. Se o teu servidor precisa mandar as
  atualização para as filiais porque não centraliza tudo de uma vez e deixa
  só o PDV de fora.
 
 Vejo que existe sim a necessidade de centralizar para então distribuir
 novamente às pontas, porém novamente, poderia optar por soluções padrão
 do próprio banco de dados.
 
  São apenas ponderações baseado no email que você mandou, não estou
 dizendo
  que está errado, apenas que pode ser melhor e mais confiável.
 
  Abraço,
  Fabiano Machado Dias
 
 
 
 
  Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu
 já
  disse: não dá pra pensar que uma replicação multi-master vai estar com
 os
  dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
  modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
  outra.
 
  Em 8 de julho de 2010 17:15,fabi...@wolaksistemas.com.br  escreveu:
 
 
  PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
  independente. O que me referi foi a forma que você implementou o
  sistema.
 
  Att,
  Fabiano Machado Dias
 
 
 
 
  --
  Atenciosamente,
  Alexsander da Rosa
  Linux User #113925
 
  Extremismo na defesa da liberdade não é defeito.
  Moderação na busca por justiça não é virtude.
  -- Barry Goldwater
  ___
  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
  

Re: [pgbr-geral] Replicação Multi-Master

[Alexsander Rosa]

Vamos por partes.

Em 8 de julho de 2010 20:51, fabi...@wolaksistemas.com.br escreveu:

 Treços do teu email:

 Há tabelas globais onde apenas um servidor pode gravar - Se esse
 servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a
 aplicação em um data center, ou seja se você depende de um central não há
 porque ter as locais afinal não vai funcionar sem as globais não é? Ou
 entendi errado?


Você entendeu errado. Estas tabelas globais são replicadas normalmente,
mas as filiais não têm permissão de escrita em suas cópias. São tabelas cuja
manutenção é centralizada -- como por exemplo, estado da federação. Se o
Congresso criar um novo estado, digamos o Pará do Sul (PS), somente um
usuário logado no servidor central (e devidamente autorizado) vai poder
criar este registro. Esta tabela não tem uma coluna id do servidor como
parte da chave primária, que no caso seria obviamente a sigla do estado,
PS. Se a empresa começar a aceitar pagamentos em tampinhas de garrafa, o
registro tampinha de garrafa com sigla e chave primária TPG poderá ser
criada apenas na central.



 Meu ERP usa um framework de persistência - Opção de cada desenvolver, eu
 por experiência recomendo passar longe desse tipo de coisa. Tomara que não
 acontece com você mas o dia que resolver dar pau, reze.


Eu mesmo desenvolvi o framework de persistência, além de uma ferramenta de
engenharia reversa e um gerador de código. O framework está bastante
otimizado (afinal, o código tem mais de 5 anos de uso em produção) e os
comandos gerados por ele foram bem depurados, não há pesquisas
desnecessárias nem exigência de OID. Ele atende perfeitamente a imensa
maioria dos casos, mas para aquelas situações onde um SQL feito à mão é
melhor existe suporte a views e stored procedures.


 grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE -
 Já citado antes a questão da integridade, mas como você falou dependendo
 do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista.
 Hoje já temos infra suficiente para manter um link decente e se a desculpa
 for a rede que pode cair, vide a NFe e o SPED.


Ainda não vi no mercado links perfeitos. Por outro lado já vi um Centro de
Distribuição ficar mais de 24h sem Internet porque os fios de cobre de todos
os links foram roubados. Não vejo como um servidor centralizado pode ser
melhor, não imagino explicar para o cliente que um processo vital como o
recebimento de mercadorias em uma filial tem que ficar parado, deixando
faltar produtos na prateleira, porque a rede está fora do ar. No caso da NFe
é diferente: o seu BD está funcionando, seu processo continua, apenas o
servidor da Fazenda que está indisponível. Imagine se cada vez que fosse
preciso emitir uma NFe em contingência, toda a empresa do cliente parasse.
Isso é o que acontece quando você roda aplicações vitais em data centers
remotos.


 um processo que roda no CRON das lojas envia estes comandos para o
 servidor central - No meu ponto de vista não é uma solução elegante.

 Elegância é subjetiva.


 O servidor central, por sua vez, envia para todas as lojas todas as
 atualizações que recebeu, também minuto a minuto. - Você centraliza,
 distribui e centraliza novamente. Se o teu servidor precisa mandar as
 atualização para as filiais porque não centraliza tudo de uma vez e deixa
 só o PDV de fora.

 O objetivo é manter os servidores idênticos: poucos minutos depois do final
do expediente, todos estão iguais. Além disso, uma filial pode querer saber
onde tem alguma mercadoria: por exemplo, pode chegar um cliente pedindo uma
coisa que está em falta naquela loja mas tem disponível em outra.



 São apenas ponderações baseado no email que você mandou, não estou dizendo
 que está errado, apenas que pode ser melhor e mais confiável.

 Abraço,
 Fabiano Machado Dias


 Agradeço seus comentários.



  Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu
 já
  disse: não dá pra pensar que uma replicação multi-master vai estar com os
  dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
  modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
  outra.
 


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Alexsandro Haag]

Sinceramente não vejo problema nas características informadas pelo 
Alexsander.

On 08-07-2010 20:51, fabi...@wolaksistemas.com.br wrote:
 Treços do teu email:

 Há tabelas globais onde apenas um servidor pode gravar - Se esse
 servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a
 aplicação em um data center, ou seja se você depende de um central não há
 porque ter as locais afinal não vai funcionar sem as globais não é? Ou
 entendi errado?

Vejo que a diferença é que há um ponto central, porém este é replicado 
para as pontas. Com isso se o ponto central estiver indisponível as 
pontas continuam funcionando.
 Meu ERP usa um framework de persistência - Opção de cada desenvolver, eu
 por experiência recomendo passar longe desse tipo de coisa. Tomara que não
 acontece com você mas o dia que resolver dar pau, reze.

Hoje os frameworks de persistência estão muito maduros e trazem 
produtividade, além de permitir uma boa independência de banco de dados. 
Pessoalmente defendo o seu uso, principalmente em grandes projetos, como 
ERPs, CRMs e afins. Mas acho perigoso tentar atender mais que 2 bancos. 
Acaba deixando tudo muito complexo de manter com o tempo.
 grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE -
 Já citado antes a questão da integridade, mas como você falou dependendo
 do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista.
 Hoje já temos infra suficiente para manter um link decente e se a desculpa
 for a rede que pode cair, vide a NFe e o SPED.

 um processo que roda no CRON das lojas envia estes comandos para o
 servidor central - No meu ponto de vista não é uma solução elegante.


Aqui concordo com o Fabiano, pois os bancos de dados já provém soluções 
para replicação. Alguns até mais de uma, como é o caso do Postgres.

 O servidor central, por sua vez, envia para todas as lojas todas as
 atualizações que recebeu, também minuto a minuto. - Você centraliza,
 distribui e centraliza novamente. Se o teu servidor precisa mandar as
 atualização para as filiais porque não centraliza tudo de uma vez e deixa
 só o PDV de fora.

Vejo que existe sim a necessidade de centralizar para então distribuir 
novamente às pontas, porém novamente, poderia optar por soluções padrão 
do próprio banco de dados.

 São apenas ponderações baseado no email que você mandou, não estou dizendo
 que está errado, apenas que pode ser melhor e mais confiável.

 Abraço,
 Fabiano Machado Dias




 Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu já
 disse: não dá pra pensar que uma replicação multi-master vai estar com os
 dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
 modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
 outra.

 Em 8 de julho de 2010 17:15,fabi...@wolaksistemas.com.br  escreveu:

  
 PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
 independente. O que me referi foi a forma que você implementou o
 sistema.

 Att,
 Fabiano Machado Dias




 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater
 ___
 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


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

Re: [pgbr-geral] Replicação Multi Master

[Gurgel, Flavio]

 Seguinte temos hoje, um banco local, 2 bancos em filiais diferentes,
 rodando a mesma aplicação, com o pgpool consigo sincronizar estes
 dados , seja daonde esse dado for inserido, so que o grande detalhe do

Não entendi. Deixe-me tentar:
Você tem 3 bancos de dados, sendo:
- 1 banco de dados central;
- 2 bancos de dados em filiais.
É isso?

Outra, você falou que em qualquer ponto onde seja feita uma alteração, você 
sincroniza. Mas de onde pra onde? Do banco centralizado pros outros, 
vice-versa? Você está usando vários pgpool, um em cada filial? E o banco 
centralizado?

 pgpool, é que estamos sincronizando via conexão de internet, e ele
 está lento
 para tal tarefa, tem como
 fazer que ele só faça inserts e drops, sem realizar selects nestes nós
 do pgpool?
 Pois é nesta hora que ele acaba ficando lento.

Pra que você faz DROP em produção?
Minha opinião é que você tem um problema de arquitetura, não só de software de 
replicação.
Também tem o fato de o pgpool não ser muito indicado para conexões lentas via 
internet, por ele ser síncrono conexões de rede locais rápidas são indicadas.

Seria interessante rever a arquitetura da sua solução como um todo antes de 
dizer o que você pode fazer.
[]s

Flavio Henrique A. Gurgel
tel. 55-11-2125.4786
cel. 55-11-8389.7635
www.4linux.com.br
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[JotaComm]

Olá,

Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda
l...@fricke.com.brescreveu:

 Bom dia pessoal,

 Estamos implementando uma replicação (sincronização) de bases com o
 Postgres,
 Testamos o Pgpool mas ele não está funcionando legal com nossa
 aplicação, tem outro produto que faça isso melhor?


Não existe replicação A melhor que replicação B, e sim a replicação mais
adequada ao ambiente.  Você poderia descrever o seu ambiente. Qual a
necessidade da replicação? Você precisa replicar todos os dados ou apenas
uma porcentagem dos dados?

A réplica precisa ficar disponível para consulta e/ou escrita ou apenas os
dados replicados já são suficientes?




 --
 Lucas Lima

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



[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Alexsander Rosa]

Eu desenvolvi uma replicação que está sendo usada pelos meus clientes (ex:
www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
consideração. Há tabelas globais onde apenas um servidor pode gravar -- a
aplicação não deixa os usuários das lojas gravarem em tabelas como
alíquotas de ICMS ou lista de UF. As demais são tabelas locais e todas
possuem como parte da chave uma coluna número da loja; por exemplo o
pedido 1234 feito na loja 7 fica com número 1234/7.

Meu ERP usa um framework de persistência que grava numa tabela separada
todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON das
lojas envia estes comandos para o servidor central (a topologia é estrela)
de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as lojas
todas as atualizações que recebeu, também minuto a minuto.

Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda
l...@fricke.com.brescreveu:

 Bom dia pessoal,

 Estamos implementando uma replicação (sincronização) de bases com o
 Postgres,
 Testamos o Pgpool mas ele não está funcionando legal com nossa
 aplicação, tem outro produto que faça isso melhor?

 --
 Lucas Lima

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




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Gurgel, Flavio]

 Estamos implementando uma replicação (sincronização) de bases com o
 Postgres, Testamos o Pgpool mas ele não está funcionando legal com
 nossa aplicação, tem outro produto que faça isso melhor?
 
 -- Lucas Lima

Seria mais simpático você fornecer o erro ou comportamento que você está 
chamando de não está funcionando legal
pgpool e pgpool2 são softwares maduros, perfeitamente integrados com o 
PostgreSQL e não dá pra citar um produto melhor. Ele pode apenas não estar 
adequado à sua solução ou vice-versa.

Flavio Henrique A. Gurgel
tel. 55-11-2125.4786
cel. 55-11-8389.7635
www.4linux.com.br
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[fabiano]

Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

Meu amigo, você já pensou em centralizar essa sua aplicação?

Você tem muitos pontos de falha, só por curiosidade como fica a
integridade do seu sistema?

Att,
Fabiano Machado Dias

 Eu desenvolvi uma replicação que está sendo usada pelos meus clientes (ex:
 www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
 consideração. Há tabelas globais onde apenas um servidor pode gravar --
 a
 aplicação não deixa os usuários das lojas gravarem em tabelas como
 alíquotas de ICMS ou lista de UF. As demais são tabelas locais e
 todas
 possuem como parte da chave uma coluna número da loja; por exemplo o
 pedido 1234 feito na loja 7 fica com número 1234/7.

 Meu ERP usa um framework de persistência que grava numa tabela separada
 todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON
 das
 lojas envia estes comandos para o servidor central (a topologia é estrela)
 de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as
 lojas
 todas as atualizações que recebeu, também minuto a minuto.

 Em 8 de julho de 2010 11:35, Lima - Lojas Fricke Ltda
 l...@fricke.com.brescreveu:

 Bom dia pessoal,

 Estamos implementando uma replicação (sincronização) de bases com o
 Postgres,
 Testamos o Pgpool mas ele não está funcionando legal com nossa
 aplicação, tem outro produto que faça isso melhor?

 --
 Lucas Lima

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




 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater
 ___
 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] Replicação Multi-Master

[Alexsander Rosa]

Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
gente que acha aceitável deixar os funcionários de braços cruzados
informando aos clientes o sistema está fora do ar, mas no comércio o furo
é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
foram roubados várias vezes seguidas, logo após a reposição. Somente quando
a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
de alguns dias online.

Se a replicação multi-master tiver sido prevista desde o início, a
integridade pode ser mantida dentro de alguma tolerância se algumas
restrições forem usadas. Existem várias coisas que a aplicação não permite
fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
dá pra pensar que uma replicação multi-master vai estar com os dados 100%
iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias

  Eu desenvolvi uma replicação que está sendo usada pelos meus clientes
 (ex:
  www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
  consideração. Há tabelas globais onde apenas um servidor pode gravar --
  a
  aplicação não deixa os usuários das lojas gravarem em tabelas como
  alíquotas de ICMS ou lista de UF. As demais são tabelas locais e
  todas
  possuem como parte da chave uma coluna número da loja; por exemplo o
  pedido 1234 feito na loja 7 fica com número 1234/7.
 
  Meu ERP usa um framework de persistência que grava numa tabela separada
  todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON
  das
  lojas envia estes comandos para o servidor central (a topologia é
 estrela)
  de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as
  lojas
  todas as atualizações que recebeu, também minuto a minuto.
 


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Ralf Schlindwein]

Faça uma relação hospedar em um DataCenter confiável X valor funcionários
parados.
Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e
Servidor e fique feliz somente gerenciando a sua TI.





Em 8 de julho de 2010 15:02, Alexsander Rosa
alexsander.r...@gmail.comescreveu:

 Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
 gente que acha aceitável deixar os funcionários de braços cruzados
 informando aos clientes o sistema está fora do ar, mas no comércio o furo
 é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
 foram roubados várias vezes seguidas, logo após a reposição. Somente quando
 a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
 de alguns dias online.

 Se a replicação multi-master tiver sido prevista desde o início, a
 integridade pode ser mantida dentro de alguma tolerância se algumas
 restrições forem usadas. Existem várias coisas que a aplicação não permite
 fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
 dá pra pensar que uma replicação multi-master vai estar com os dados 100%
 iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
 feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

 Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias

  Eu desenvolvi uma replicação que está sendo usada pelos meus clientes
 (ex:
  www.casadopapel.com.br), mas meu ERP foi projetado levando isto em
  consideração. Há tabelas globais onde apenas um servidor pode gravar
 --
  a
  aplicação não deixa os usuários das lojas gravarem em tabelas como
  alíquotas de ICMS ou lista de UF. As demais são tabelas locais e
  todas
  possuem como parte da chave uma coluna número da loja; por exemplo o
  pedido 1234 feito na loja 7 fica com número 1234/7.
 
  Meu ERP usa um framework de persistência que grava numa tabela separada
  todos os comandos INSERT, UPDATE e DELETE; um processo que roda no CRON
  das
  lojas envia estes comandos para o servidor central (a topologia é
 estrela)
  de 1 em 1 minuto. O servidor central, por sua vez, envia para todas as
  lojas
  todas as atualizações que recebeu, também minuto a minuto.
 


 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater

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




-- 
Ralf Schlindwein
Analista de Sistemas
ralfoa...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Alexsander Rosa]

Sabia que a legislação exige que os caixas com ECF continuem emitindo cupons
mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o cabo de
rede, o PDV tem que continuar funcionando. Isto existe para evitar que
sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de que
o sistema está fora do ar. A integridade vai pro espaço por exigência da
legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc.

Todas as grandes redes de supermercados possuem bancos de dados locais, um
em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por
exigência legal -- possuem dados locais. Neste contexto, pensar em hospedar
em Data Center não faz o menor sentido: o Walmart, por exemplo, recebe
dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um
atraso de um minuto está de bom tamanho.

Em 8 de julho de 2010 15:09, Ralf Schlindwein ralfoa...@gmail.comescreveu:

 Faça uma relação hospedar em um DataCenter confiável X valor funcionários
 parados.
 Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e
 Servidor e fique feliz somente gerenciando a sua TI.





 Em 8 de julho de 2010 15:02, Alexsander Rosa 
 alexsander.r...@gmail.comescreveu:

 Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
 gente que acha aceitável deixar os funcionários de braços cruzados
 informando aos clientes o sistema está fora do ar, mas no comércio o furo
 é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
 foram roubados várias vezes seguidas, logo após a reposição. Somente quando
 a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
 de alguns dias online.

 Se a replicação multi-master tiver sido prevista desde o início, a
 integridade pode ser mantida dentro de alguma tolerância se algumas
 restrições forem usadas. Existem várias coisas que a aplicação não permite
 fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
 dá pra pensar que uma replicação multi-master vai estar com os dados 100%
 iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
 feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

 Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias


-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[Kauí Aires Oliveira]

Boa Tarde a todos...

Ótima observação Alexsander e isso falando dos relacionais, até chegar no
RPAS, Oracle Retail. Não vi com bons olhos a solução dele, para não falar
outra coisa...

[]

Att,

Kaui Aires
DBA (Oracle, PostgreSql), System Analyst, Security Analyst
Skype: kauiaires

Campaign: Before you ask: Search on google.com

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.


Em 8 de julho de 2010 15:37, Alexsander Rosa
alexsander.r...@gmail.comescreveu:

 Sabia que a legislação exige que os caixas com ECF continuem emitindo
 cupons mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o
 cabo de rede, o PDV tem que continuar funcionando. Isto existe para evitar
 que sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de
 que o sistema está fora do ar. A integridade vai pro espaço por exigência
 da legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc.

 Todas as grandes redes de supermercados possuem bancos de dados locais, um
 em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por
 exigência legal -- possuem dados locais. Neste contexto, pensar em hospedar
 em Data Center não faz o menor sentido: o Walmart, por exemplo, recebe
 dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um
 atraso de um minuto está de bom tamanho.

 Em 8 de julho de 2010 15:09, Ralf Schlindwein ralfoa...@gmail.comescreveu:

 Faça uma relação hospedar em um DataCenter confiável X valor funcionários
 parados.
 Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e
 Servidor e fique feliz somente gerenciando a sua TI.





 Em 8 de julho de 2010 15:02, Alexsander Rosa 
 alexsander.r...@gmail.comescreveu:

 Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que tem
 gente que acha aceitável deixar os funcionários de braços cruzados
 informando aos clientes o sistema está fora do ar, mas no comércio o furo
 é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos postes
 foram roubados várias vezes seguidas, logo após a reposição. Somente quando
 a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar mais
 de alguns dias online.

 Se a replicação multi-master tiver sido prevista desde o início, a
 integridade pode ser mantida dentro de alguma tolerância se algumas
 restrições forem usadas. Existem várias coisas que a aplicação não permite
 fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo. Não
 dá pra pensar que uma replicação multi-master vai estar com os dados 100%
 iguais em todos os servidores ao mesmo tempo, é óbvio que uma modificação
 feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

 Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias


 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater

 ___
 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] Replicação Multi-Master

[fabiano]

PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
independente. O que me referi foi a forma que você implementou o sistema.

Att,
Fabiano Machado Dias


 Sabia que a legislação exige que os caixas com ECF continuem emitindo
 cupons
 mesmo com a rede LOCAL derrubada? Se você cortar com um alicate o cabo de
 rede, o PDV tem que continuar funcionando. Isto existe para evitar que
 sonegadores parem de emitir cupons mas sigam vendendo, com a desculpa de
 que
 o sistema está fora do ar. A integridade vai pro espaço por exigência da
 legislação... procure no Google sobre coisas como PAF, ECF, TEF, etc.

 Todas as grandes redes de supermercados possuem bancos de dados locais, um
 em cada caixa. Alguns são MySQL, outros são arquivos DBF, mas todos -- por
 exigência legal -- possuem dados locais. Neste contexto, pensar em
 hospedar
 em Data Center não faz o menor sentido: o Walmart, por exemplo, recebe
 dados das filiais em nivel GLOBAL de hora em hora. Para uma rede menor, um
 atraso de um minuto está de bom tamanho.

 Em 8 de julho de 2010 15:09, Ralf Schlindwein
 ralfoa...@gmail.comescreveu:

 Faça uma relação hospedar em um DataCenter confiável X valor
 funcionários
 parados.
 Hospede em um DataCenter e faça um contrato de gerenciamento de Banco e
 Servidor e fique feliz somente gerenciando a sua TI.





 Em 8 de julho de 2010 15:02, Alexsander Rosa
 alexsander.r...@gmail.comescreveu:

 Centralizar = parar de vender quando a rede cair? Nem pensar. Sei que
 tem
 gente que acha aceitável deixar os funcionários de braços cruzados
 informando aos clientes o sistema está fora do ar, mas no comércio o
 furo
 é mais embaixo. Em uma das lojas, por exemplo, os FIOS de cobre dos
 postes
 foram roubados várias vezes seguidas, logo após a reposição. Somente
 quando
 a companhia telefônica colocou fibra ótica é que a rede conseguiu ficar
 mais
 de alguns dias online.

 Se a replicação multi-master tiver sido prevista desde o início, a
 integridade pode ser mantida dentro de alguma tolerância se algumas
 restrições forem usadas. Existem várias coisas que a aplicação não
 permite
 fazer e não há usuários rodando pgAdmin direto nas bases, por exemplo.
 Não
 dá pra pensar que uma replicação multi-master vai estar com os dados
 100%
 iguais em todos os servidores ao mesmo tempo, é óbvio que uma
 modificação
 feita numa filial pode levar 2 ou 3 minutos para chegar em outra.

 Em 8 de julho de 2010 14:03, fabi...@wolaksistemas.com.br escreveu:

 Meu Deus, me deu 3 tipos de arrepio ao ler essa descrição.

 Meu amigo, você já pensou em centralizar essa sua aplicação?

 Você tem muitos pontos de falha, só por curiosidade como fica a
 integridade do seu sistema?

 Att,
 Fabiano Machado Dias


 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater
 ___
 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] Replicação Multi-Master

[Alexsander Rosa]

Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu já
disse: não dá pra pensar que uma replicação multi-master vai estar com os
dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
outra.

Em 8 de julho de 2010 17:15, fabi...@wolaksistemas.com.br escreveu:


 PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
 independente. O que me referi foi a forma que você implementou o sistema.

 Att,
 Fabiano Machado Dias




-- 
Atenciosamente,
Alexsander da Rosa
Linux User #113925

Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude.
-- Barry Goldwater
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação Multi-Master

[fabiano]

Treços do teu email:

Há tabelas globais onde apenas um servidor pode gravar - Se esse
servidor cair ??? Ou seja você centralizou, qual a diferença de colocar a
aplicação em um data center, ou seja se você depende de um central não há
porque ter as locais afinal não vai funcionar sem as globais não é? Ou
entendi errado?

Meu ERP usa um framework de persistência - Opção de cada desenvolver, eu
por experiência recomendo passar longe desse tipo de coisa. Tomara que não
acontece com você mas o dia que resolver dar pau, reze.

grava numa tabela separada todos os comandos INSERT, UPDATE e DELETE -
Já citado antes a questão da integridade, mas como você falou dependendo
do tipo de aplicação pode ser tolerável, mas não no meu ponto de vista.
Hoje já temos infra suficiente para manter um link decente e se a desculpa
for a rede que pode cair, vide a NFe e o SPED.

um processo que roda no CRON das lojas envia estes comandos para o
servidor central - No meu ponto de vista não é uma solução elegante.

O servidor central, por sua vez, envia para todas as lojas todas as
atualizações que recebeu, também minuto a minuto. - Você centraliza,
distribui e centraliza novamente. Se o teu servidor precisa mandar as
atualização para as filiais porque não centraliza tudo de uma vez e deixa
só o PDV de fora.


São apenas ponderações baseado no email que você mandou, não estou dizendo
que está errado, apenas que pode ser melhor e mais confiável.

Abraço,
Fabiano Machado Dias



 Pode dar um exemplo dos muitos pontos de falha que você mencionou? Eu já
 disse: não dá pra pensar que uma replicação multi-master vai estar com os
 dados 100% iguais em todos os servidores ao mesmo tempo, é óbvio que uma
 modificação feita numa filial pode levar 2 ou 3 minutos para chegar em
 outra.

 Em 8 de julho de 2010 17:15, fabi...@wolaksistemas.com.br escreveu:


 PDV é uma coisa, quem trabalha com ERP sabe que os caixas devem rodar
 independente. O que me referi foi a forma que você implementou o
 sistema.

 Att,
 Fabiano Machado Dias




 --
 Atenciosamente,
 Alexsander da Rosa
 Linux User #113925

 Extremismo na defesa da liberdade não é defeito.
 Moderação na busca por justiça não é virtude.
 -- Barry Goldwater
 ___
 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