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
