Hohoho... este é um tema realmente bacana... difícil mesmo!
Bom, em sistemas muito grandes, pode ser interessante ir atrás de uma solução real de replicação multimaster assíncrona, em sistemas menores, todos sabem que ninguém tem fôlego para fazer isto funcionar direito. A melhor forma, na minha opinião é abrir mão de alguns recursos (impor restrições de atualização e extração de informações) e alterar significativamente a modelagem do sistema. A) Pense no conceito de bancos de dados distribuídos. Eles são de modelagem complexa, mas são soluções muito antigas e já possuem inúmeras implementações neste sentido. B) Pense em replicação Master Slave assíncrona. É muito mais fácil pensar assim, pois você sabe onde estão as informações mais atualizadas de uma tabela. C) Pense em particionamento de tabelas por região geográfica. Isto não é obrigatório, mas é uma forma de pensar na junção de várias porções de uma tabela espalhadas em bancos distintos em um todo "quase" consistente. D) Pense nos blocos que são atualizados com frequência na matriz e os blocos que são atualizados com frequência nas filiais. O lado master da replicação sempre deve estar na ponta que sofre mais atualizações. No caso de você terá várias replicações multimaster em paralelo, com um banco de dados numa filial atuando como master na porção de dados que só dizem respeito a aquela filial e como slave no tocante ao restante dos dados. 5) Entenda as limitações de frequência de atualização e imponha regras na aplicação, quando um lado slave estiver desatualizado por um período maior do que o permitido. Pense nos relatórios periódicos, e em qual situação eles podem ser gerados em em qual abrangência. Bom, ninguém disse que é uma solução simples. Mas depende de pouca tecnologia no sentido de usar uma modalidade de replicação já bem estabelecida como o Slony-I. O lado da aplicação exigem muito estudo cuidadoso e bastante retrabalho. No entanto, fazer isso nunca foi simples, as aplicações onde isso funciona geralmente já nascem com uma modelagem apropriada para isso. Se fosse tranquilo fazer replicação multimaster assíncrona, mais gente utilizaria. Muita gente enfrenta os problemas que o Euler citou. Imagine uma situação mais drástica... bancos!!! Já pensou em quantas agências espalhadas? E se cai a comunicação de uma agência??? Você pode continuar operando localmente? Já imaginou a diversidade de informações que uma agência pode alterar durante uma transação? Bancos não se arriscam, investem pesado em boas linhas de comunicação, e quando elas falham a agência fica literalmente fora do ar... perdendo muito dinheiro, mas não correndo o risco de corromper as informações durante uma sincronia posterior. Agora uma situação mais comum é o de força de vendas que tem vendedores com notebooks fazendo consultas localmente e fechando transações em clientes. Note que o vendedor só pode fazer alterações num pedaço muito pequeno das informações. O sistema tem de estar modelado para isolar cada vendedor no momento da sincronia de informações. Neste momento o vendedor é o master em relação às vendas dele e slave em relação a todo o resto dos dados. Bom, por enquanto é só pessoal! []s Fábio Telles Em 01/06/07, Euler Taveira de Oliveira <[EMAIL PROTECTED]> escreveu:
Leandro Guimarães Faria Corcete DUTRA wrote: > Seria mais sábio, a meu ver, pesquisar qual projeto tem os mesmos > objetivos que o teu (imagino que o Slony II) e colaborar com eles, em > vez de correr por fora. Slony II já nasceu morto infelizmente. :( Mas o Slony-II seria um sistema multi-master síncrono (hoje temos o pgcluster nessa categoria). Como você ressaltou Leandro as dificuldades de implementar um sistema de replicação multi-master assíncrono são imensas. Porque? Simplesmente pela complexidade de resolução de alguns tipos de conflitos. Os conflitos mais comuns nesse tipo de sistema: 1) conflito de atualização: o registro X pode ser atualizado no servidor A e antes do síncronismo o mesmo registro X é atualizado no servidor B. Neste caso o que fazer? 2) conflito de remoção: o registro X pode ser removido no servidor A e antes do sincronismo o mesmo registro X pode já ter sido removido ou pior, ele foi atualizado. Neste caso o que fazer? 3) conflito de unicidade: o registro X foi inserido no servidor A com a chave K e ante do sincronismo um outro registro Y foi inserido no servidor B com a mesma chave K. Neste caso o que fazer? 4) conflito de DDL: uma tabela, visão, função ou gatilho X foi criado no servidor A e antes do sincronismo um objeto Y de mesmo nome e com definição diferente foi inserido no servidor B. Neste caso o que fazer? Essas são somente algumas, e vejam que nenhum dos conflitos é de fácil resolução. Todos eles precisam de intervenção de um especialista. Na literatura os autores ilustram um módulo desse tipo de sistema de replicação chamado "conflict resolution handler", ou seja, gerenciador de resolução de conflitos. Se mesmo assim queira implementar algo do gênero, sugiro que o seu sistema não tenha caminhos que levem a um dos conflitos citados acima e outros que não citei. -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
-- site: http://www.midstorm.org/~telles/ e-mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] sip:[EMAIL PROTECTED]
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
