Como a replicação de mesclagem detecta e resolve conflitos

A replicação de mesclagem permite que vários nós façam alterações de dados autônomas, portanto, existem situações em que uma alteração feita em um nó pode entrar em conflito com uma alteração feita nos mesmos dados em outro nó. Em outras situações, o Merge Agent encontra um erro como uma violação de restrição e não pode propagar uma alteração feita em um nó específico para outro nó. Este artigo descreve tipos de conflitos, como conflitos são detectados e resolvidos e fatores que afetam a detecção e a resolução.

Detectar e resolver conflitos

O Agente de Mesclagem detecta conflitos usando a coluna lineage da tabela de sistema; se o rastreamento no nível da coluna estiver habilitado para um artigo, a coluna COLV1 também será usada. Essas colunas contêm metadados sobre quando uma linha ou coluna é inserida ou atualizada e sobre quais nós em uma topologia de replicação de mesclagem fizeram alterações na linha ou coluna. Você pode usar o procedimento armazenado do sistema sp_showrowreplicainfo para exibir esses metadados.

À medida que o Merge Agent enumera as alterações a serem aplicadas durante a sincronização, ele compara os metadados de cada linha no Publicador e no Assinante. O Merge Agent usa esses metadados para determinar se uma linha ou coluna foi alterada em mais de um nó na topologia, o que indica um possível conflito. Depois que um conflito é detectado, o Merge Agent inicia o resolvedor de conflitos especificado para o artigo com um conflito e usa o resolvedor para determinar o vencedor do conflito. A linha vencedora é aplicada ao Publicador e ao Assinante, e os dados da linha perdedora são gravados em uma tabela de conflitos.

Os conflitos são resolvidos automaticamente e imediatamente pelo Merge Agent, a menos que você tenha escolhido a resolução interativa de conflitos para o artigo. Para obter informações, consulte Resolvedor de Conflitos Interativos da Replicação da Microsoft. Se você alterar manualmente a linha vencedora para um conflito usando o Visualizador de conflitos de replicação de mesclagem, o Agente de Mesclagem aplicará a versão vencedora da linha ao servidor perdedor durante a próxima sincronização.

Conflitos resolvidos por log

Depois que o Merge Agent resolver o conflito de acordo com a lógica no resolvedor de conflitos, ele registra dados de conflito de acordo com o tipo de conflito:

• Para conflitos UPDATE e INSERT, ele grava a versão perdedora da linha na tabela de conflitos do artigo, que possui o nome no formato conflict_<PublicationName>_<ArticleName>. As informações gerais de conflito, como o tipo de conflito, são gravadas na tabela MSmerge_conflicts_info.

• Para conflitos DELETE, ele grava a versão perdedora da linha na tabela MSmerge_conflicts_info. Quando uma operação de exclusão perde para uma atualização, não há dados para a linha perdedora (porque foi uma exclusão), então nada é gravado em conflict_<PublicationName>_<ArticleName>.

As tabelas de conflito para cada artigo são criadas no banco de dados de publicação, no banco de dados de assinatura ou em ambos (o padrão), dependendo do valor especificado para o parâmetro @conflict_logging de sp_addmergepublication. Cada tabela de conflitos tem a mesma estrutura do artigo no qual se baseia, com a adição da origin_datasource_id coluna. O Agente de Mesclagem excluirá dados da tabela de conflitos se eles forem mais antigos do que o período de retenção de conflitos para publicação, que é especificado usando o parâmetro @conflict_retention de sp_addmergepublication (o padrão é 14 dias).

A replicação fornece o Visualizador de Conflitos de Replicação e procedimentos armazenados (sp_helpmergearticleconflicts, sp_helpmergeconflictrows, e sp_helpmergedeleteconflictrows) para exibir dados de conflito. Para obter mais informações, consulte o gerenciamento de conflitos para replicação por mesclagem.

Fatores que afetam a resolução de conflitos

Há dois fatores que afetam a forma como o Merge Agent resolve um conflito detectado:

• O tipo de assinatura: cliente ou servidor (se a assinatura é uma assinatura pull ou uma assinatura push não afeta a resolução de conflitos).

• O tipo de rastreamento de conflito usado: nível de linha, nível de coluna ou nível de registro lógico.

Tipos de assinatura

Ao criar uma assinatura, além de especificar se ela é uma assinatura push ou pull, especifique se ela é uma assinatura de cliente ou servidor; depois que uma assinatura é criada, o tipo não pode ser alterado (em versões anteriores do SQL Server, assinaturas de cliente e servidor foram referidas, respectivamente, como assinaturas locais e globais).

Uma assinatura com um valor de prioridade atribuído (de 0,00 a 99,99) é chamada de assinatura de servidor; uma assinatura usando o valor de prioridade do Publicador é chamada de assinatura de cliente. Além disso, assinantes com assinaturas de servidor podem republicar dados para outros Assinantes. A tabela a seguir resume as principais diferenças e usos de cada tipo de Assinante.

Se uma linha for alterada em uma assinatura do cliente, nenhuma prioridade será atribuída à alteração até que a assinatura seja sincronizada. Durante a sincronização, as alterações do Assinante recebem a prioridade do Publicador e mantêm essa prioridade para sincronizações subsequentes. De certa forma, o Publicador assume a propriedade da alteração. Esse comportamento permite que o primeiro Assinante sincronize com o Publicador para vencer conflitos subsequentes com outros Assinantes para uma determinada linha ou coluna.

Quando você altera uma linha em uma assinatura de servidor, a prioridade da assinatura é armazenada nos metadados da alteração. Esse valor de prioridade acompanha a linha alterada à medida que se integra com alterações em outros Assinantes. Isso garante que uma alteração feita por uma assinatura de prioridade mais alta não perca para uma alteração subsequente feita por uma assinatura com uma prioridade mais baixa.

Uma assinatura não pode ter um valor de prioridade explícito que seja maior que seu Publicador. O Editor de nível superior em uma topologia de replicação de mesclagem sempre tem um valor de prioridade explícito de 100,00. Todas as assinaturas dessa publicação devem ter um valor de prioridade menor que esse valor. Em uma topologia de republicação:

• Se o Assinante estiver republicando dados, a assinatura deverá ser uma assinatura de servidor com um valor de prioridade menor que o Publicador acima do Assinante.

• Se o Assinante não estiver republicando dados (porque ele está no nível folha da árvore de republicação), a assinatura deverá ser do cliente.

Para obter mais informações sobre assinaturas de servidor e prioridades, consulte Exemplo de resolução de conflitos de mesclagem com base no tipo de assinatura e prioridades atribuídas.

Notificação de conflito atrasada

Notificações de conflito atrasadas podem ocorrer com assinaturas de servidor que têm prioridades de conflito diferentes. Considere o cenário a seguir, no qual as alterações não conflitantes são trocadas entre o Publicador e um Assinante de menor prioridade que resultam em alterações conflitantes quando um Assinante de prioridade mais alta é sincronizado com o Publicador:

1. O Publicador e um Assinante de baixa prioridade, chamado LowPrioritySub, compartilham alterações durante várias sincronizações sem conflitos.

2. Um Assinante de prioridade mais alta, chamado HighPrioritySub, não é sincronizado com o Editor há algum tempo e fez alterações nas mesmas linhas que o Assinante LowPrioritySub.

3. O Assinante do HighPrioritySub é sincronizado com o Editor e vence os conflitos entre suas alterações e o Assinante LowPrioritySub porque tem uma prioridade maior do que o Assinante LowPrioritySub. O Editor agora contém as alterações feitas pelo Assinante HighPrioritySub.

4. O Assinante LowPrioritySub é mesclado com o Editor e faz download de um grande número de alterações devido aos conflitos com o Assinante HighPrioritySub.

Essa situação pode se tornar problemática quando o Assinante de menor prioridade fez alterações nas mesmas linhas que agora são perdedoras de conflito. Isso pode resultar na perda de todas as alterações feitas por este Assinante. Uma solução potencial para esse problema é garantir que todos os Assinantes tenham a mesma prioridade, a menos que a lógica de negócios determine o contrário.

Nível de acompanhamento

Se uma alteração de dados se qualifica ou não como um conflito depende do tipo de controle de conflitos definido para um artigo: nível de linha, nível de coluna ou nível de registro lógico. Para obter mais informações sobre o acompanhamento em nível de registro lógico, consulte Conflito de Replicação de Mesclagem Avançada – Resolvendo em Registro Lógico.

Quando os conflitos são reconhecidos no nível da linha, as alterações feitas nas linhas correspondentes são julgadas como um conflito, independentemente de as alterações serem feitas ou não na mesma coluna. Por exemplo, suponha que uma alteração seja feita na coluna de endereço de uma linha do Publicador e uma segunda alteração seja feita na coluna número de telefone da linha do Assinante correspondente (na mesma tabela). Com o acompanhamento em nível de linha, um conflito é detectado porque foram feitas alterações na mesma linha. Com o acompanhamento no nível da coluna, nenhum conflito é detectado, pois foram feitas alterações em colunas diferentes na mesma linha.

Para o acompanhamento nos níveis de linha e de coluna, a resolução do conflito é a mesma: toda a linha de dados é substituída por dados do vencedor do conflito (para acompanhamento no nível do registro lógico, a resolução depende da propriedade logical_record_level_conflict_resolutiondo artigo).

A semântica do aplicativo geralmente determina qual opção de acompanhamento usar. Por exemplo, se você estiver atualizando os dados do cliente que geralmente são inseridos ao mesmo tempo, como um endereço e um número de telefone, é recomendado escolher o acompanhamento em nível de linha. Se o acompanhamento em nível de coluna foi escolhido nessa situação, as alterações no endereço do cliente em um local e no número de telefone do cliente em outro local não seriam detectadas como um conflito: os dados seriam mesclados na sincronização e o erro seria perdido. Em outras situações, atualizar colunas individuais de sites diferentes pode ser a escolha mais lógica. Por exemplo, dois sites podem ter acesso a diferentes tipos de informações estatísticas em um cliente, como nível de renda e valor total em dólar de compras de cartão de crédito. Selecionar o acompanhamento em nível de coluna garante que ambos os sites possam inserir os dados estatísticos para colunas diferentes sem gerar conflitos desnecessários.

Tipos de conflito

Embora a maioria dos conflitos esteja relacionada a atualizações (uma atualização em um nó entra em conflito com uma atualização ou exclusão em outro nó), há outros tipos de conflito. Cada tipo de conflito discutido nesta seção pode ocorrer durante a fase de upload ou a fase de download do processamento de mesclagem. O processamento de upload é a primeira reconciliação das alterações executadas em uma sessão de mesclagem específica e é a fase durante a qual o Merge Agent replica as alterações do Assinante até o Publicador. Os conflitos detectados durante esse processamento são conhecidos como conflitos de upload. O processamento de download envolve a movimentação de alterações do Publicador para o Assinante e ocorre após o processamento de upload. Conflitos durante essa fase de processamento são conhecidos como conflitos de download.

Para obter mais informações sobre tipos de conflito, consulte MSmerge_conflicts_info, especialmente as colunas conflict_type e reason_code.

Conflitos de atualizações simultâneas

O Merge Agent detecta conflitos de atualizações quando uma atualização para uma linha (ou coluna, ou registro lógico) em um nó entra em conflito com outra atualização para a mesma linha em outro nó. O comportamento do resolvedor padrão nesse caso é enviar a versão vencedora da linha para o nó perdedor e registrar a versão da linha perdedora na tabela de conflitos do artigo.

Conflitos entre atualização e exclusão

O Merge Agent detecta conflitos de atualização-exclusão quando uma atualização de dados em um nó entra em conflito com a exclusão em outro. Nesse caso, o Merge Agent atualiza uma linha; no entanto, quando o Merge Agent pesquisa essa linha no destino, ele não consegue encontrar a linha porque ela foi excluída. Se o vencedor for o nó que atualizou a linha, a exclusão no nó perdedor será descartada, e o Agente de Mesclagem enviará a linha recém-atualizada para o perdedor do conflito. O Agente de Mesclagem registra informações sobre a versão perdedora da linha na tabela MSmerge_conflicts_info.

Conflitos de alterações com falha

O Merge Agent gera esses conflitos quando não pode aplicar uma alteração específica. Isso normalmente ocorre devido a uma diferença nas definições de restrição entre o publicador e o assinante e ao uso da propriedade NOT FOR REPLICATION (NFR) na restrição. Os exemplos incluem:

• Um conflito de chave estrangeira no Assinante, que pode ocorrer quando a restrição do lado do Assinante não está marcada como NFR.

• As diferenças nas restrições entre o Editor e os Assinantes e as restrições não são marcadas como NFR.

• Indisponibilidade de objetos dependentes no Assinante. Por exemplo, se você publicar uma visualização, mas não a tabela da qual essa visualização depende, haverá uma falha se você tentar inserir por meio dessa visualização no Assinante.

• Combine a lógica de filtragem de uma publicação que não corresponde às restrições de chave primária e de chave estrangeira. Conflitos podem ocorrer quando o mecanismo relacional do SQL Server tenta cumprir uma restrição, mas o Merge Agent está respeitando a definição de filtro de junção entre os artigos. O Merge Agent não pode aplicar a alteração no nó de destino devido às restrições no nível da tabela, o que resulta em um conflito.

• Conflitos devido a violações de índice exclusivo, restrição exclusiva ou chave primária podem ocorrer se colunas de identidade estiverem definidas para o artigo e o gerenciamento automatizado dessas identidades não for utilizado. Isso pode ser um problema se dois Assinantes usarem o mesmo valor de identidade para uma linha recém-inserida. Para obter mais informações sobre o gerenciamento do intervalo de identidades, consulte Replicar Colunas de Identidade.

• Conflitos devido à lógica de gatilho que impede o Agente de Mesclagem de inserir uma linha na tabela de destino. Considere um gatilho de atualização definido no Assinante; o gatilho não está marcado como NFR e inclui um ROLLBACK em sua lógica. Se ocorrer falha, o gatilho emitirá um ROLLBACK da transação, o que fará com que o Agente de Mesclagem detecte um conflito de alteração com falha.

Conteúdo relacionado

• Replicação de mesclagem
• MSmerge_conflicts_info (Transact-SQL)
• MSmerge_contents (Transact-SQL)
• sp_addmergepublication (Transact-SQL)
• sp_helpmergearticleconflicts (Transact-SQL)
• sp_helpmergeconflictrows (Transact-SQL)
• sp_helpmergedeleteconflictrows (Transact-SQL)
• Controlar o comportamento de gatilhos e restrições na sincronização
• Detecção e resolução avançadas de conflitos de replicação de mesclagem
• Republicar dados