On 6/1/07, Euler Taveira de Oliveira <[EMAIL PROTECTED]> wrote: Bem... Alguns dos casos abaixo eu tentei implementar uma solução :
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?
- O sistema faz verificação coluna a coluna e se uma delas foi alterada no servidor B em posterior a alteração no servidor A, esta não será propagada, pois em algum momento, esta alteração no servidor B chegará ao servidor A.
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?
- Neste caso o DELETE terá prioridade. (Como disse no e-mail anterior, para o meu caso isto funcionará perfeitamente, já que minha aplicação executa pouquíssimas operaçãoes de delete. Mas para um sistema genérico isto deverá ser melhorado).
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?
É neste caso que estou trabalhando no momento. O que eue estou tentando desenvolver seria algo +/- assim : Antes de propagar um INSERT, verifico todas as chaves UNIQUE e se já existir alguma no servidor remoto, terei que atualizar a chave primária do registro e manter o restante das informções do registro mais recente (formando um resultado dos dois registros) e verificar todas as chaves estrangeiras desse registro para atualizar suas chaves e propaga-las.
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?
Esta situação não me preocupa (Para implatação no meu projeto), pois a modificação de estrutura será feita sempre a partir de uma única base e propagada para todas as outras.
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.
Com certeza a resolução de conflitos é a parte mais complicada deste tipo de sistema. Mas estou tentando diminuir ao máximo a possibilidade de isso acontecer...
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.
Não é questão de vontade e sim necessidade ... Sei que este tipo de sistema pode causar inconsistencia e outros problemas, mas infelizmente, no Brasil, não podemos contar um serviço razoável de acesso a internet por um custo ACESSÍVEL. O sistema já está funcionando, mas ainda precisa de ajustes,melhorias e algumas ferramentas para monitoramento e gerenciamento do mesmo. Agradeço o interesse e participação de todos... Isso está me ajudando muito ... A troca de experiencias e conhecimento enriquesse muito os projetos. Coloco-me a disposição ... Att: Thiago Risso _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
