Como a replicação de mesclagem deteta 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 os tipos de conflitos, como os conflitos são detetados e resolvidos e os fatores que afetam a deteção e a resolução.

Detetar e resolver conflitos

O Merge Agent deteta conflitos usando a coluna lineage da tabela MSmerge_contents do sistema; se o rastreamento ao nível da coluna estiver ativado para um artigo, a coluna COLV1 também será utilizada. 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 conflito potencial. Depois que um conflito é detetado, 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 no Editor e no Assinante, e os dados da linha perdedora são gravados numa tabela de conflitos.

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

Registrar conflitos resolvidos

Depois que o Merge Agent tiver resolvido o conflito de acordo com a lógica no solucionador de conflitos, ele registrará os dados do conflito de acordo com o tipo de conflito:

• Para conflitos de UPDATE e INSERT, ele registra a versão perdida da linha na tabela de conflitos associada ao objeto, que é nomeada na forma conflict_<PublicationName>_<ArticleName>. As informações gerais sobre conflitos, como o tipo de conflito, são gravadas na tabela MSmerge_conflicts_info.

• Para DELETE conflitos, ele grava a versão perdida da linha na MSmerge_conflicts_info tabela. Quando uma exclusão perde em relação a 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 na base de dados de publicação, na base de dados de subscrição ou em ambos (por padrão), dependendo do valor especificado para o @conflict_logging parâmetro 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 Merge Agent exclui dados da tabela de conflitos se os dados forem mais antigos do que o período de retenção de conflitos para a publicação, que é especificado usando o @conflict_retention parâmetro 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_helpmergeconflictrowse sp_helpmergedeleteconflictrows) para exibir dados de conflito. Para obter mais informações, consulte Resolução de conflitos para replicação de fusão.

Fatores que afetam a resolução de conflitos

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

• 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 conflitos usado: nível de linha, nível de coluna ou nível de registo lógico.

Tipos de subscrição

Ao criar uma assinatura, além de especificar se é uma assinatura push ou pull, você especifica se é 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, as assinaturas de cliente e servidor eram 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 Publisher é chamada de assinatura de cliente. Além disso, os Subscritores com subscrições de servidor podem voltar a publicar dados para outros Subscritores. A tabela a seguir resume as principais diferenças e usos de cada tipo de assinante.

Se uma linha for alterada em uma assinatura de 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 Editor e mantêm essa prioridade para sincronizações subsequentes. Em certo sentido, a Editora assume a propriedade da mudança. Esse comportamento permite que o primeiro Assinante sincronize com o Editor para resolver conflitos subsequentes a seu favor em relação a 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 viaja com a linha alterada à medida que se funde com as alterações em outros assinantes. Isso garante que uma alteração feita por uma assinatura de prioridade mais alta não seja perdida para uma alteração subsequente feita por uma assinatura com prioridade mais baixa.

Uma subscrição não pode ter um valor de prioridade explícito superior ao seu Editor. O Publicador 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 inferior a 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 do que o Editor acima do Assinante.

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

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

Notificação de conflito atrasada

Notificações de conflito atrasadas podem ocorrer em assinaturas de servidor com prioridades de conflito diferentes. Considere o seguinte cenário, no qual alterações não conflitantes são trocadas entre o Editor e um Assinante de prioridade mais baixa que resultam em alterações conflitantes quando um Assinante de prioridade mais alta sincroniza com o Editor:

1. O Publicador e o Assinante de baixa prioridade, chamado LowPrioritySub, trocam alterações durante várias sincronizações sem conflito.

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

3. O Assinante HighPrioritySub sincroniza com o Publicador e vence os conflitos entre as suas alterações e as do Assinante LowPrioritySub porque tem uma prioridade mais alta do que este último. O Publicador agora contém as alterações feitas pelo Assinante HighPrioritySub.

4. Em seguida, o Assinante LowPrioritySub combina-se com o Publicador e descarrega um grande número de alterações devido a conflitos com o Assinante HighPrioritySub.

Esta situação pode tornar-se problemática quando o Subscritor de prioridade mais baixa tiver feito alterações nas mesmas linhas que agora são perdedoras de conflitos. Isso pode resultar na perda de todas as alterações feitas por este Assinante. Uma possível solução 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 rastreamento

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 rastreamento ao nível de registo lógico, consulte Advanced Merge Replication Conflict - Resolving in Logical Record.

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 ou não feitas na mesma coluna. Por exemplo, suponha que uma alteração seja feita na coluna de endereço de uma linha do Publisher e uma segunda alteração seja feita na coluna de número de telefone da linha Assinante correspondente (na mesma tabela). Com o rastreamento em nível de linha, um conflito é detetado porque foram feitas alterações na mesma linha. Com o rastreamento em nível de coluna, nenhum conflito é detetado, porque foram feitas alterações em colunas diferentes na mesma linha.

Para o rastreamento em nível de linha e coluna, a resolução do conflito é a mesma: toda a linha de dados é substituída por dados do vencedor do conflito (para rastreamento em nível de 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 rastreamento usar. Por exemplo, se você estiver atualizando dados de clientes que geralmente são inseridos ao mesmo tempo, como um endereço e um número de telefone, o rastreamento no nível da linha deve ser escolhido. Se o rastreamento em nível de coluna fosse 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 detetadas 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 sobre um cliente, como nível de renda e valor total em dólares de compras com cartão de crédito. A seleção de rastreamento no 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ó), existem 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 de alterações realizadas 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 Editor. Os conflitos detetados durante esse processamento são chamados de conflitos de upload. O processamento de download envolve a movimentação de alterações do Editor para o Assinante e ocorre após o processamento do upload. Os conflitos durante esta fase de processamento são referidos como conflitos de download.

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

Conflitos de atualizações

O Merge Agent deteta conflitos de atualização-atualização quando uma atualização de uma linha (ou coluna, ou registo 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 neste caso é enviar a versão vencedora da linha para o nó perdedor e registrar a versão da linha perdida na tabela de conflito do artigo.

Conflitos de atualização/exclusão

O Merge Agent deteta conflitos de atualização-exclusão quando uma atualização de dados em um nó entra em conflito com uma exclusão em outro. Nesse caso, o Merge Agent atualiza uma linha; no entanto, quando o Merge Agent procura 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 Merge Agent enviará a linha recém-atualizada para o perdedor do conflito. O Merge Agent registra informações sobre a versão perdida da linha na MSmerge_conflicts_info tabela.

Conflitos devido a alterações falhadas

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 (NFR) na restrição NOT FOR REPLICATION. 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.

• 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 Subscritor. Por exemplo, se você publicar um modo de exibição, mas não a tabela da qual esse modo de exibição depende, ocorrerá uma falha se você tentar inserir por meio desse modo de exibição no Assinante.

• Junte a lógica de filtragem para uma publicação que não corresponde à chave primária e às restrições de chave estrangeira. Conflitos podem ocorrer quando o mecanismo relacional do SQL Server tenta honrar uma restrição, mas o Merge Agent está honrando 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 ou restrição exclusiva ou violações de chave primária podem ocorrer se colunas de identidade forem definidas para o artigo e o gerenciamento automatizado de identidades não for usado. Isso pode ser um problema se dois assinantes usarem o mesmo valor de identidade para uma linha recém-inserida. Para mais informações sobre a gestão de intervalos para colunas de identidade, consulte Replicar Colunas de Identidade.

• Conflitos devido à lógica de acionador que impede o Merge Agent de inserir uma linha na tabela de destino. Considere um gatilho de atualização definido no subscritor; o gatilho não está marcado como NFR e inclui um ROLLBACK na sua lógica. Se ocorrer uma falha, o gatilho emitirá um ROLLBACK da transação, o que resulta na deteção de um conflito de alteração falhada pelo Merge Agent.

Conteúdo relacionado

• Replicação de intercalação
• 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
• Replicação avançada de fusão - deteção e resolução de conflitos
• Republicar dados