>> Ordem de aplicação de cada tupla inserida ou modificada dentro de uma >> transação única. > > Interessante... e a rigor não era para isso acontecer, visto que a tabela > "rr_pending_changes" em um "id" sequencial e também um "timestamp" do > momento da modificação.
É fato. Mas se você olhar o código, verá que o Rubyrep abre várias threads, e cada thread faz um select na tabela de pendências de forma paralela. Tentei resolver isso sem sucesso, fazendo com que cada thread pegasse o primeiro da fila pela ordem do sequencial. Só que como as threads são parelelas, não dá pra saber qual vai fazer o trabalho primeiro e, provavelmente por isso, a ordem de aplicação pode não ser obedecida. O problema que ocorria, inclusive, era aleatório. Teria que alterar o código para que cada thread pegasse toda uma transação e cuidasse dela, mesmo assim teria risco de errar a ordem. Por essa e por outras razões, os mecanismos do Bucardo, Slony e Londiste tem uma thread ou processo solitário para o controle da fila da replicação, e acho que a arquitetura do Rubyrep é problemática. O Rubyrep é uma solução interessante, todavia, quando é necessário sincronizar dados entre PostgreSQL e MySQL - ele fala com os dois. Mas só valerá pra sincronização inicial. O Rubyrep também deve funcionar bem quando está replicando tabelas que: - não tem chaves estrangeiras; - tem chaves estrangeiras com tabelas estáticas; - tem chaves estrangeiras com tabelas que não participam da replicação. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
