Thiago Risso wrote: >> 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. > Não entendi o que quis dizer aqui. Você está dizendo que neste cenário, o dado que prevalece é o do servidor B? Por que?
>> 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). > Como assim o DELETE terá prioridade? Se o dado que se está querendo remover é algo que está errado e o UPDATE faz a correção do mesmo. Neste caso não vejo o porquê priorizar uma operação ou outra. A interferência de um especialista num caso genérico é inevitável. >> 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. > Isso é um operação que degrada a performance dos servidores A e B no momento do sincronismo. Talvez se você trabalhar com alocação de chaves por período de tempo seja uma solução razoável para o seu cenário. > 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... > Bom, concordo com o que o Fábio disse, e acho que neste caso é mais uma questão de adequação do modelo de dados e da aplicação do que de um sistema de replicação complexo. > 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. > Bom quanto sei que infelizmente o acesso a um canal de informações é caro. Mas soluções exigem restrições. Se a sua clientela alvo pode pagar por isso porque não ter algumas restrições? -- 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
