Re: [pgbr-geral] Material para replicação de dados Multi-master
2013/5/22 Fábio Thomaz fabio_...@yahoo.com.br Alguém já usou ou tem algo a dizer sobre esta ferramenta: Postgres-XC Postgres-XC pode ser considerado cluster multi-master, mas o propósito é diferente do que você está buscando. Este foi criado, de forma superficial, para um cluster de alto desempenho com escalabilidade horizontal para escrita e leitura. Distribuir nós de um cluster Postgres-XC fisicamente vai piorar o desempenho ao invés de melhorar. Nesse caso seria melhor uma master/slave mesmo (ou até o XC mas num local central). Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
Alguém já usou ou tem algo a dizer sobre esta ferramenta: Postgres-XC Att, Fábio Thomaz Em 16 de maio de 2013 13:02, Fábio Thomaz fabio_...@yahoo.com.br escreveu: Olá Anexsander, Estive fazendo um levantamento de algumas ferramentas que poderiam me ajudar com isto, dentre as que replicam Mestre-Meste estão: 1 - Bucardo; 2 - SymmetricDS; 3 - RubyRep; 4 - Daffodil Replicator; Algum dos colegas usa alguma destas soluções? Se sim, poderiam comentar sobre a experiência do uso com estas ferramentas? Att, Fábio Thomaz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
2013/5/16 Euler Taveira eu...@timbira.com.br On 16-05-2013 16:00, Alexsander Rosa wrote: Não achei esta mensagem do Euler que você respondeu... Vide o histórico [1] da lista. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2013-May/034934.html No meu Gmail caiu tudo como SPAM dizendo várias pessoas marcaram como spam. Estranho, não? -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
Em 16 de maio de 2013 00:44, Euler Taveira eu...@timbira.com.br 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 é. Já pensei em algo assim, considerando N filiais e uma matriz: - um DB global onde a matriz é master e as filiais são slave; - N DB locais onde cada filial é master e a matriz é slave; - cada filial teria apenas 2 databases, o global (ro) e seu local (rw) - na matriz haveria N+1 databases, o global (rw) mais N locais (ro) - uma aplicação rodando na matriz atualizando o Global lendo os DB locais; - uma replicação Matriz - Filiais master/slave (nativa do PG, por exemplo); - N replicações Filial - Matriz master/slave (nativa do PG, por exemplo); - a solução de conflitos seria na aplicação que atualiza o BD global; - as PK artificiais incluiriam o código N da filial quando necessário. -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
On 17-05-2013 14:17, Alexsander Rosa wrote: Já pensei em algo assim, considerando N filiais e uma matriz: - um DB global onde a matriz é master e as filiais são slave; - N DB locais onde cada filial é master e a matriz é slave; - cada filial teria apenas 2 databases, o global (ro) e seu local (rw) - na matriz haveria N+1 databases, o global (rw) mais N locais (ro) - uma aplicação rodando na matriz atualizando o Global lendo os DB locais; - uma replicação Matriz - Filiais master/slave (nativa do PG, por exemplo); - N replicações Filial - Matriz master/slave (nativa do PG, por exemplo); - a solução de conflitos seria na aplicação que atualiza o BD global; - as PK artificiais incluiriam o código N da filial quando necessário. Talvez ao invés de bancos de dados você utilizasse esquemas. Replicação nativa não daria certo (ela replica toda instância); a não ser que você tenha mais de uma instância. Além disso, você não precisaria de replicação nas duas direções; apenas uma já seria suficiente. -- 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] Material para replicação de dados Multi-master
Em 17 de maio de 2013 14:23, Euler Taveira eu...@timbira.com.br escreveu: On 17-05-2013 14:17, Alexsander Rosa wrote: Já pensei em algo assim, considerando N filiais e uma matriz: - um DB global onde a matriz é master e as filiais são slave; - N DB locais onde cada filial é master e a matriz é slave; - cada filial teria apenas 2 databases, o global (ro) e seu local (rw) - na matriz haveria N+1 databases, o global (rw) mais N locais (ro) - uma aplicação rodando na matriz atualizando o Global lendo os DB locais; - uma replicação Matriz - Filiais master/slave (nativa do PG, por exemplo); - N replicações Filial - Matriz master/slave (nativa do PG, por exemplo); - a solução de conflitos seria na aplicação que atualiza o BD global; - as PK artificiais incluiriam o código N da filial quando necessário. Talvez ao invés de bancos de dados você utilizasse esquemas. Replicação nativa não daria certo (ela replica toda instância); a não ser que você tenha mais de uma instância. Além disso, você não precisaria de replicação nas duas direções; apenas uma já seria suficiente. Apenas numa direção, Matriz - Filiais? Ou apenas Filiais - Matriz? Como? -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
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 eu...@timbira.com.br 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
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] Material para replicação de dados Multi-master
On 16-05-2013 10:18, Fábio Thomaz wrote: [evite top-posting] - 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; É um cenário mais realista. 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. Geralmente o inbound (entrada) *não* é taxado; somente o outbound (saída). 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. Fuja disso! Tecnicamente frágil. -- 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] Material para replicação de dados Multi-master
Em 15 de maio de 2013 20:51, Fábio Thomaz fabio_...@yahoo.com.br escreveu: Olá pessoal, sou iniciante no uso do PostgreSQL, entrei na lista recentemente e venho em busca de maiores informações para que eu possa criar um modelo que atenda um cliente. 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. 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. Bem, com estas informações acima, os nobres colegas do grupo poderiam me ajudar, direcionando-me a fontes de pesquisa onde eu possa implementar este cenário? Desde já agradeço Att, Fábio Thomaz Olhou o Bucardo? -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
Olá Anexsander, Estive fazendo um levantamento de algumas ferramentas que poderiam me ajudar com isto, dentre as que replicam Mestre-Meste estão: 1 - Bucardo; 2 - SymmetricDS; 3 - RubyRep; 4 - Daffodil Replicator; Algum dos colegas usa alguma destas soluções? Se sim, poderiam comentar sobre a experiência do uso com estas ferramentas? Att, Fábio Thomaz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
Em 16-05-2013 13:02, Fábio Thomaz escreveu: Olá Anexsander, Estive fazendo um levantamento de algumas ferramentas que poderiam me ajudar com isto, dentre as que replicam Mestre-Meste estão: 1 - Bucardo; 2 - SymmetricDS; 3 - RubyRep; 4 - Daffodil Replicator; Algum dos colegas usa alguma destas soluções? Se sim, poderiam comentar sobre a experiência do uso com estas ferramentas? Já usei Bucardo e Rubyrep. Ambas são programas de um homem só e tive problemas de consistência de replicação com o Rubyrep que *não* consegui resolver. O Bucardo é bastante estável, mas como toda replicação multi-mestre exige planejamento e cuidado na implantação. Mas tenho ele em produção em alguns lugares com alto grau de sucesso. Recomendo que você teste num ambiente controlado e siga adiante. Não existe mágica. Você terá que aprender a usar corretamente. []s __ Flavio Henrique A. Gurgel Líder de Projetos Especiais Consultoria, Projetos Treinamentos 4LINUX Tel1: +55-11.2125-4747 ou 2125-4748 www.4linux.com.br email: fla...@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] Material para replicação de dados Multi-master
Olá Euler, Quando você diz: Fuja disso! Tecnicamente frágil., seria pela possível falha na geração deste número sequencial negativo? Pois para estas tabelas pensei em ter uma sequencia normal, mas sendo chamada através de um Trigger que iria capturar o próximo valor, multiplicar por -1 e atribuir ao campo. Neste caso eu também terei que padronizar algumas coisas, tipo, se o ID vier nulo do meu comento SQL de inclusão, o banco pega o valor da sequencia e pronto, se vier com o valor 0 por exemplo, o Trigger testa o valor e gera um valor negativo. Há, e neste caso eu teria duas sequencias para a mesma tabela, uma sequencia normal e outra apenas para esta ocasião dos negativos, lembrando que seria apenas em algumas tabelas usadas em recursos que o sistema não irá poder parar, o restante eu informo que a operação está indisponível por problemas de comunicação com o servidor e pronto. Att, Fábio Thomaz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
On 16-05-2013 13:15, Fábio Thomaz wrote: Quando você diz: Fuja disso! Tecnicamente frágil., seria pela possível falha na geração deste número sequencial negativo? Não. Imagine você ter que corrigir uma chave estrangeira em n tabelas a cada inserção, atualização ou remoção? É muito trabalhoso além de ser susceptível a falha. E se múltiplas instâncias pegarem o mesmo valor? Como será a resolução de conflitos? Minimize os pontos de falha no projeto adicionando alguns requisitos tais como supor que a conexão *não* vai falhar em 99% dos casos; 1% é o risco assumido. Lembre-se, não existe 100% de garantia em uma solução (nem mesmo uma que custa 10⁶ dilmas). Há, e neste caso eu teria duas sequencias para a mesma tabela, uma sequencia normal e outra apenas para esta ocasião dos negativos, lembrando que seria apenas em algumas tabelas usadas em recursos que o sistema não irá poder parar, o restante eu informo que a operação está indisponível por problemas de comunicação com o servidor e pronto. Isso complicaria muito a sua integridade referencial. Lembre-se de seguir o princípio KISS. -- 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] Material para replicação de dados Multi-master
Em 16 de maio de 2013 13:15, Fábio Thomaz fabio_...@yahoo.com.br escreveu: Olá Euler, Quando você diz: Fuja disso! Tecnicamente frágil., seria pela possível falha na geração deste número sequencial negativo? Pois para estas tabelas pensei em ter uma sequencia normal, mas sendo chamada através de um Trigger que iria capturar o próximo valor, multiplicar por -1 e atribuir ao campo. Neste caso eu também terei que padronizar algumas coisas, tipo, se o ID vier nulo do meu comento SQL de inclusão, o banco pega o valor da sequencia e pronto, se vier com o valor 0 por exemplo, o Trigger testa o valor e gera um valor negativo. Há, e neste caso eu teria duas sequencias para a mesma tabela, uma sequencia normal e outra apenas para esta ocasião dos negativos, lembrando que seria apenas em algumas tabelas usadas em recursos que o sistema não irá poder parar, o restante eu informo que a operação está indisponível por problemas de comunicação com o servidor e pronto. Att, Fábio Thomaz Não achei esta mensagem do Euler que você respondeu... -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
Olá Alexsander, está uma mensagem antes de você entrar nesta thread: 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. Fuja disso! Tecnicamente frágil. Att, Fábio Thomaz Em 16 de maio de 2013 16:00, Alexsander Rosa alexsander.r...@gmail.comescreveu: Em 16 de maio de 2013 13:15, Fábio Thomaz fabio_...@yahoo.com.brescreveu: Olá Euler, Quando você diz: Fuja disso! Tecnicamente frágil., seria pela possível falha na geração deste número sequencial negativo? Pois para estas tabelas pensei em ter uma sequencia normal, mas sendo chamada através de um Trigger que iria capturar o próximo valor, multiplicar por -1 e atribuir ao campo. Neste caso eu também terei que padronizar algumas coisas, tipo, se o ID vier nulo do meu comento SQL de inclusão, o banco pega o valor da sequencia e pronto, se vier com o valor 0 por exemplo, o Trigger testa o valor e gera um valor negativo. Há, e neste caso eu teria duas sequencias para a mesma tabela, uma sequencia normal e outra apenas para esta ocasião dos negativos, lembrando que seria apenas em algumas tabelas usadas em recursos que o sistema não irá poder parar, o restante eu informo que a operação está indisponível por problemas de comunicação com o servidor e pronto. Att, Fábio Thomaz Não achei esta mensagem do Euler que você respondeu... -- Atenciosamente, Alexsander da Rosa ___ 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] Material para replicação de dados Multi-master
On 16-05-2013 16:00, Alexsander Rosa wrote: Não achei esta mensagem do Euler que você respondeu... Vide o histórico [1] da lista. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2013-May/034934.html -- 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
[pgbr-geral] Material para replicação de dados Multi-master
Olá pessoal, sou iniciante no uso do PostgreSQL, entrei na lista recentemente e venho em busca de maiores informações para que eu possa criar um modelo que atenda um cliente. 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. 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. Bem, com estas informações acima, os nobres colegas do grupo poderiam me ajudar, direcionando-me a fontes de pesquisa onde eu possa implementar este cenário? Desde já agradeço Att, Fábio Thomaz ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Material para replicação de dados Multi-master
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 pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
