olá pessoal. Sinceramente, estou me "metendo" em um "duelo de titans", porém já trabalhei em um sistema de replicação de dados. talvez, minha curta experiência nisso possa ajudar... =)
O sistema era para replicar dados somente. Vou tentar ilustrar a necessidade: Uma empresa tinha várias filiais. e eles trabalhavam com um sistema que utilizava uns arquivos .mdb (vulgo access se não me falha a memória). A matriz, a cada vez que atualiza sua base de dados, enviava uma cópia por email para as suas filiais para que se atualizassem. Também existia a ocasião onde a franquia mandava informações para a matriz. Esse envio era feito através de arquivos texto. O problema, obviamente, é que a informação demorava muito para ser atualizada ou simplesmente não conseguia ser atualizada e, em alguns casos, causava até prejuízo devido a uma informação equivocada. É interessante comentar que cada filial encontram-se em municípios e até estados diferentes. Solucionamos da seguinte forma: Criamos um webservice em cada uma das filiais. Na matriz foi "mais simples", foi criado um daemon configurável que acessa os webservices das filiais de tempos em tempos. Para transferir os dados, foi criado uma tabela de movimentações nas filiais e uma mais incrementada na matriz. A cada verificada do daemon, para a primeira filial estivesse on-line, era criado um "pacote" com todas as movimentações e enviado as filiais. Toda vez que o daemon estive online novamente, ele verificava se a filial já havia recebido os pacotes anteriores antes de enviar o novo. Bom, no resumo, acho que é isso. Espero ter ajudado. Abraço a todos. On 6/2/07, Euler Taveira de Oliveira < [EMAIL PROTECTED]> wrote:
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
-- Atenciosamente, Sebastian Selau Webber Colombo Acessem e participem do fórum de postgresql brazuca: http://postgresql.blog.br/forum/ Sl 67.1-2: "Ó Deus, tem misericórdia de nós e abençoa-nos! Trata-nos com bondade. Assim o mundo inteiro conhecerá a tua vontade, e a tua salvação será conhecida por todos os povos".
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
