Olá Euler,
Primeiramente muito obrigado por suas considerações!
Baseado nas dificuldades em manter múltiplos masters sincronizados,
estive pensando em estar criando o seguinte senário:
-> 1 banco na nuvem e um em cada unidade;
-> Usar a replicação nativa hoje existente: Nuvem -> Bancos Locais;
-> Fazer alterações apenas na Nuvem, conectando o sistema pela internet;
-> Direcionar a conexão para a base local apenas para consultas, estas
usadas para relatórios ou caso a conexão venha a cair, fazendo que pelo
menos o cliente possa consultar as informações no sistema até que a conexão
seja restabelecida;
Neste caso acima eu teria que investir em banda de internet, já que todos
os registros que subirem para o servidor, irão voltar novamente para
sincronizar a base principal, passando estes registros pela rede esterna
duas vezes, o que não seria muito legal.
Também estive pensando em liberar operações em algumas partes críticas do
sistema na base local, gerando uma PK com uma sequência de valores que ao
invés de ser incrementada, seria decrementada a partir de zero, tendo assim
uma sequência negativa. Estas, após o restabelecimento da conexão, seriam
transportadas para o servidor principal, e neste momento, receberiam uma
"PK real".
Para o uso da chave primária desta forma, estou criando os campos desta
forma:
create table nome_tabela(
id integer NOT NULL DEFAULT nextval('nome_sequencia'::regclass),
...
);
Será que existirá algum grave problema com isto?
Att,
Fábio Thomaz
Em 16 de maio de 2013 00:44, Euler Taveira <[email protected]> escreveu:
> On 15-05-2013 20:51, Fábio Thomaz wrote:
> > O cenário é básico: 1 matriz e 3 filiais precisando compartilhar
> > informações, onde algumas destas informações (tabelas) serão únicas para
> > todas as filiais, como um exemplo eu poderia dar o cadastro de produto.
> >
> Não é.
>
> > Pensei em criar uma aplicação que acessasse o servidor na nuvem, mas
> > não posso correr o risco de deixar a empresa sem sistema por uma
> > eventual falha na rede externa.
> >
> > Então teríamos 5 SGDB's: Nuvem (Principal), Matriz, Filial-1, Filial-2
> > , Filial-3.
> >
> É um cenário complexo e, se tratando de SGBD, você tem que procurar um
> cenário mais simples possível. Aconselho que veja a literatura [1][2][3]
> sobre a complexidade de um cenário com múltiplos mestres e
> principalmente sobre resolução de conflitos.
>
> Sobre a sua arquitetura, minimize ao máximo o número de servidores
> principais (aka master). Dependendo do seu orçamento, eu pensaria em
> investir mais em infraestrutura (a não ser que seu cliente esteja
> localizado no Amapá ou Roraima, por exemplo -- onde a disponibilidade de
> bons links é quase escassa) do que em uma solução complexa que (i) é
> frágil tecnicamente e (ii) a manutenção toma muito tempo.
>
> Já vou logo adiantando que não há como ter algo transparente (a não ser
> que vá adotar algum middleware "perfeito") para a aplicação com esse
> cenário, ou seja, a aplicação deve ser moldada para isso.
>
> Sobre as soluções para Postgres, começe por [4] (está meio desatualizado
> mas ainda é uma boa fonte).
>
> [1]
> http://www.amazon.com/Database-Systems-Complete-Book-Edition/dp/0131873253
> [2]
>
> http://www.amazon.com/Database-System-Concepts-Abraham-Silberschatz/dp/0073523321
> [3]
>
> http://www.amazon.com/Database-Management-Systems-Raghu-Ramakrishnan/dp/0072465638
> [4]
>
> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling
>
>
> --
> 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
