Replicação de tabela bidirecional em SDs simétricas
A replicação da tabela bidirecional não é trivial porque você deve lidar com todo tipo de conflito que possa surgir. Um conflito de exemplo é quando uma linha é inserida no servidor e no cliente, que juntos violariam uma chave exclusiva. Tanto o cliente quanto o servidor permitem que a inserção / atualização ocorra porque eles não sabem que há uma atualização de entrada que violaria a chave.
O mecanismo de sincronização dos dois lados pensa: "Ah, não, nós dois dissemos aos nossos usuários que não havia problema em adicionar essa linha com base no que sabíamos, mas não podemos sincronizar agora porque isso violaria a exclusividade".
O mecanismo de sincronização tem uma opção:
1. Take the last insert/update by timestamp and destroy the request that came
first. This is undesirable because the first person thought they committed,
successfully when in reality their transaction was erased without anyone's
consent.
2. Reject both rows, if I can't make everyone happy, I'm not letting anything
through, and log the conflict to an external table to be dealt with later.
The two users who thought they submitted data will find their transaction
in a queue.
3. Merge the rows, take a little from one, and a little from the other, and
create a hybrid row. Or take one or the other based on some priority system
or based on how filled out it is.
Este é apenas um exemplo de um conflito. Existem centenas de circunstâncias concebíveis onde um conflito surgiria que você deve planejar.
As centenas de circunstâncias concebíveis em que um conflito pode acontecer devem ter uma ação corretiva definida na tabela de configuração: sym_conflict .
Você poderia direcionar symmetricDS para mesclar as linhas de acordo com as regras, negar as transações até que um humano tenha revisado as linhas ou até mesmo programado para jogar fora o bebê com a água do banho. Isso é definido em Capítulo 3.8 do guia do usuário , configurando conflitos e resolução de dados.
O número de possíveis conflitos baseia-se na configuração e nas limitações da sua tabela de banco de dados. À medida que você adiciona condições e limitações à sua tabela, o número de possíveis conflitos aumenta exponencialmente. Se você tiver chaves exclusivas, precisará preparar conflitos de chave exclusivos e definir resoluções. Se você tiver chaves primárias / estrangeiras em outras tabelas, precisará de resoluções de conflitos para elas. Se você obtiver 90% dos conflitos, mas perder alguns, então, quando os conflitos ocorrerem, os bancos de dados não serão idênticos no cliente e no servidor.