>> 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?
Não... O dado que prevalecerá será o mais recente. Ex: Na tabela pessoa o nome e o endereço é alterado às 08:00 no servidor A. No Servidor B, o nome é alterado às 08:01. Neste caso o servidor A irá propagar apenas a atualização no endereço, pois o nome foi alterado posteriormente neste servidor e, hora ou outra, esta alteração irá chegar até o 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). > 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.
Bem... Pensemos em um sistema WEB... Dois individuos utilizando o sistema resolvem abrir ao mesmo tempo a ficha de um cliente ... O individuo A, resolve alterar alguns dados, enquanto o indivíduo B resolve excluir a ficha deste cliente ... Quem prevalecerá ? (Só um exemplo, em meu modelo, o cliente não pode ser excluído, assim como a grande maioria das informações - Apenas pode ser marcada como excluída. )
>> 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 haverá degradação de performance... E é por isso que estou repensando sobre este conceito quanto a unicidade.
> 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.
Vou tentar explicar um pouco melhor do que se trata o sistema em questão e o porque preciso implementar essa ou alguma outra solução. Trata-se de um sistema que gerencia todos os processos de consultorias e agencias de emprego. O cadastro/alteração do currículo pode ser feito tanto através do site quanto através do próprio sistema. Existe também muitos outros processos que são gerenciados como clientes, processos, vagas, contratos, etc. Situação 1 : Nem todas as filiais terão servidor interno, portanto a parte do sistema que roda WEB, deverá continuar ativa e o servidor deve ser de BD deve estar sincronizado com as demais filiais que possuam servidor interno. Situação 2: O servidor Web ainda deve permanecer ativo, pois esta é a principal forma de cadastros da "MATÉRIA PRIMA" das agencias/consultorias, que são as pessoas. Situação 3: Se eu impor restrições de Somente consulta, por exemplo, durante o período de falha do link, de nada adiantará, pois o gerenciamento dos processo internos é feito basicamente de INSERT's e UPDATE's. Que tipo de modelo de dados vocês poderiam propor para algo desse tipo? Pensei em replicação MMA devido a seguinte condição : - Normalmente,o "link" não ficará durante muito tempo fora do ar, o que propicia redução de conflitos, pois na maioria do tempo, os servidores estarão online e os dados estariam consistentes e todos os NÓS.
> 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?
Eu concordo com você.... Pena que minha diretoria não... E eles estão tentando focar em um outro nicho e eles acham que o que impede é justamente isso. Então exigiram uma solução. Agradeço as sugestões e, quanto mais, melhor .... Att: Thiago Risso _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
