Compartir a través de

Cómo detecta y resuelve conflictos la replicación por mezcla

La replicación de mezcla permite que varios nodos realicen cambios de datos autónomos, por lo que existen situaciones en las que un cambio realizado en un nodo podría entrar en conflicto con un cambio realizado en los mismos datos en otro nodo. En otras situaciones, el Agente de mezcla encuentra un error como una infracción de restricción y no puede propagar un cambio realizado en un nodo determinado a otro nodo. En este artículo se describen los tipos de conflictos, cómo se detectan y resuelven los conflictos y los factores que afectan a la detección y resolución.

Detección y resolución de conflictos

El agente de mezcla detecta los conflictos usando la columna lineage de la tabla del sistema MSmerge_contents; si el seguimiento a nivel de columna está habilitado para un artículo, también se usa la columna COLV1. Estas columnas contienen metadatos sobre cuándo se inserta o actualiza una fila o columna, y sobre qué nodos de una topología de replicación de mezcla realizó cambios en la fila o columna. Puede usar el procedimiento almacenado de sistema sp_showrowreplicainfo para ver estos metadatos.

A medida que el Agente de mezcla enumera los cambios que se aplicarán durante la sincronización, compara los metadatos de cada fila en el publicador y el suscriptor. El Agente de mezcla usa estos metadatos para determinar si una fila o columna ha cambiado en más de un nodo de la topología, lo que indica un posible conflicto. Una vez detectado un conflicto, el Agente de mezcla inicia el solucionador de conflictos especificado para el artículo con un conflicto y usa la resolución para determinar el ganador del conflicto. La fila ganadora se aplica en el publicador y en el suscriptor, y los datos de la fila perdedora se escriben en una tabla de conflictos.

El Agente de mezcla resuelve automáticamente e inmediatamente los conflictos a menos que haya elegido la resolución interactiva de conflictos para el artículo. Para obtener más información, consulte Solucionador de conflictos interactivos de replicación de Microsoft. Si cambia manualmente la fila ganadora de un conflicto mediante el Visor de conflictos de replicación de mezcla, el Agente de mezcla aplica la versión ganadora de la fila al servidor que pierde durante la siguiente sincronización.

Registrar conflictos resueltos

Después de que el Agente de mezcla haya resuelto el conflicto según la lógica del solucionador de conflictos, registra los datos de conflicto según el tipo de conflicto:

  • Para los conflictos de UPDATE y INSERT, escribe la versión perdedora de la fila en la tabla de conflictos del artículo, que recibe el nombre con el formato conflict_<PublicationName>_<ArticleName>. La información general de conflictos, como el tipo de conflicto, se escribe en la tabla MSmerge_conflicts_info.

  • Para los conflictos de DELETE, escribe la versión perdedora de la fila en la tabla MSmerge_conflicts_info. Cuando una eliminación pierde frente a una actualización, no hay datos para la fila perdedora (porque era una eliminación), por lo que no se escribe nada en conflict_<PublicationName>_<ArticleName>.

Las tablas de conflictos de cada artículo se crean en la base de datos de publicación, la base de datos de suscripciones o ambas (el valor predeterminado), en función del valor especificado para el @conflict_logging parámetro de sp_addmergepublication. Cada tabla de conflictos tiene la misma estructura que el artículo en el que se basa, con la adición de la origin_datasource_id columna. El agente de mezcla elimina los datos de la tabla de conflictos si son anteriores al período de retención de conflictos de la publicación, que se especifica mediante el parámetro @conflict_retention de sp_addmergepublication (el valor predeterminado es 14 días).

La replicación proporciona el Visor de conflictos de replicación y los procedimientos almacenados (sp_helpmergearticleconflicts, sp_helpmergeconflictrowsy sp_helpmergedeleteconflictrows) para ver los datos en conflicto. Para obtener más información, consulte Resolución de conflictos para la replicación por combinación.

Factores que afectan a la resolución de conflictos

Hay dos factores que afectan a la forma en que el Agente de mezcla resuelve un conflicto que ha detectado:

  • El tipo de suscripción: cliente o servidor (si la suscripción es una suscripción pull o una suscripción push no afecta a la resolución de conflictos).

  • Tipo de seguimiento de conflictos usado: nivel de fila, nivel de columna o nivel de registro lógico.

Tipos de suscripción

Al crear una suscripción, además de especificar si se trata de una suscripción de inserción o extracción, se especifica si es una suscripción de cliente o servidor; Después de crear una suscripción, no se puede cambiar el tipo (en versiones anteriores de SQL Server, se hacía referencia a las suscripciones de cliente y servidor, respectivamente, como suscripciones locales y globales).

Una suscripción con un valor de prioridad asignado (de 0,00 a 99,99) se denomina suscripción de servidor; una suscripción que usa el valor de prioridad del publicador se denomina suscripción de cliente. Además, los suscriptores con suscripciones de servidor pueden volver a publicar datos en otros suscriptores. En la tabla siguiente se resumen las principales diferencias y usos de cada tipo de suscriptor.

Tipo Valor de prioridad Utilizado
Servidor Asignado por el usuario Si desea que los distintos suscriptores tengan prioridades diferentes.
Cliente 0,00, pero los cambios en los datos asumen el valor de prioridad del publicador tras la sincronización. Cuando desea que todos los suscriptores tengan la misma prioridad y el primer suscriptor se combine con el publicador para ganar el conflicto.

Si se cambia una fila en una suscripción de cliente, no se asigna ninguna prioridad al cambio hasta que se sincroniza la suscripción. Durante la sincronización, los cambios del suscriptor tienen asignada la prioridad del publicador y conservan esa prioridad para las sincronizaciones posteriores. En cierto sentido, el publicador asume la propiedad del cambio. Este comportamiento permite que el primer suscriptor se sincronice con el publicador para ganar conflictos posteriores con otros suscriptores para una fila o columna determinada.

Al cambiar una fila de una suscripción de servidor, la prioridad de la suscripción se almacena en los metadatos del cambio. Este valor de prioridad viaja con la fila modificada a medida que se mezcla con los cambios de otros suscriptores. Esto garantiza que un cambio realizado por una suscripción de prioridad más alta no pierde a un cambio posterior realizado por una suscripción con una prioridad menor.

Una suscripción no puede tener un valor de prioridad explícito mayor que su publicador. El publicador de nivel superior en una topología de replicación de mezcla siempre tiene un valor de prioridad explícito de 100,00. Todas las suscripciones a esa publicación deben tener un valor de prioridad menor que este valor. En una topología de replicación:

  • Si el suscriptor vuelve a publicar datos, la suscripción debe ser una suscripción de servidor con un valor de prioridad menor que el publicador encima del suscriptor.

  • Si el suscriptor no está volviendo a publicar datos (porque se encuentran en el nivel inferior del árbol de republicación) , la suscripción debe ser una suscripción de cliente.

Para obtener más información sobre las suscripciones y prioridades de servidor, vea Ejemplo de resolución de conflictos de mezcla en función del tipo de suscripción y las prioridades asignadas.

Notificación de conflictos retrasada

La notificación retrasada de conflictos puede ocurrir con suscripciones de servidor que tienen distintas prioridades de conflicto. Tenga en cuenta el siguiente escenario, en el que los cambios no conflictivos se intercambian entre el publicador y un suscriptor de prioridad inferior que da lugar a cambios en conflicto cuando un suscriptor de mayor prioridad se sincroniza con el publicador:

  1. El publicador y un suscriptor de prioridad baja, denominado LowPrioritySub, intercambian cambios en varias sincronizaciones sin conflictos.

  2. Un suscriptor de mayor prioridad, denominado HighPrioritySub, no se ha sincronizado con el publicador en algún momento y ha realizado cambios en las mismas filas que ha realizado el suscriptor de LowPrioritySub.

  3. El suscriptor HighPrioritySub se sincroniza con el publicador y gana los conflictos entre sus cambios y el suscriptor LowPrioritySub porque tiene una prioridad mayor que el suscriptor LowPrioritySub. El publicador ahora contiene los cambios realizados por el suscriptor HighPrioritySub.

  4. El suscriptor LowPrioritySub se mezcla con el publicador y descarga un gran número de cambios debido a los conflictos con el suscriptor HighPrioritySub.

Esta situación puede resultar problemática cuando el suscriptor con menor prioridad ha realizado cambios en las mismas filas que ahora son perdedoras en el conflicto. Esto puede dar lugar a una pérdida de todos los cambios realizados por este suscriptor. Una posible solución a este problema es asegurarse de que todos los suscriptores tienen la misma prioridad, a menos que la lógica de negocios determine lo contrario.

Nivel de seguimiento

Si un cambio de datos se califica como un conflicto depende del tipo de seguimiento de conflictos establecido para un artículo: nivel de fila, nivel de columna o nivel de registro lógico. Para obtener más información sobre el seguimiento de registros a nivel lógico, consulte Conflicto de replicación de combinación avanzada: resolución en registro lógico.

Cuando se reconocen conflictos en el nivel de fila, los cambios realizados en las filas correspondientes se consideran un conflicto, independientemente de si los cambios se realizan en la misma columna. Por ejemplo, supongamos que se realiza un cambio en la columna de dirección de una fila del publicador y se realiza un segundo cambio en la columna número de teléfono de la fila suscriptor correspondiente (en la misma tabla). Con el seguimiento del nivel de fila, se detecta un conflicto porque se realizaron cambios en la misma fila. Con el seguimiento de nivel de columna, no se detecta ningún conflicto, ya que se realizaron cambios en columnas diferentes de la misma fila.

Para el seguimiento a nivel de fila y columna, la resolución del conflicto es la misma: toda la fila de datos se sobrescribe con los datos del ganador del conflicto (para el seguimiento a nivel de registro lógico, la resolución depende de la propiedad del artículo logical_record_level_conflict_resolution).

La semántica de la aplicación normalmente determina qué opción de seguimiento se va a usar. Por ejemplo, si va a actualizar datos de clientes que generalmente se introducen al mismo tiempo, como una dirección y un número de teléfono, debe elegirse el seguimiento a nivel de fila. Si se eligió el seguimiento de nivel de columna en esta situación, los cambios en la dirección del cliente en una ubicación y el número de teléfono del cliente en otra ubicación no se detectarían como un conflicto: los datos se combinarían en la sincronización y se perdería el error. En otras situaciones, actualizar columnas individuales de sitios diferentes podría ser la opción más lógica. Por ejemplo, dos sitios pueden tener acceso a diferentes tipos de información estadística en un cliente, como el nivel de ingresos, y la cantidad total de dólares de las compras de tarjetas de crédito. La selección del seguimiento de nivel de columna garantiza que ambos sitios puedan especificar los datos estadísticos de diferentes columnas sin generar conflictos innecesarios.

Nota:

Si la aplicación no requiere seguimiento de nivel de columna, se recomienda usar el seguimiento de nivel de fila (valor predeterminado), ya que normalmente da como resultado un mejor rendimiento de sincronización. Si se usa el seguimiento de filas, la tabla base puede incluir un máximo de 1024 columnas, pero las columnas deben filtrarse desde el artículo para que se publique un máximo de 246 columnas. Si se utiliza el seguimiento por columna, la tabla base puede incluir 246 columnas como máximo.

Tipos de conflictos

Aunque la mayoría de los conflictos están relacionados con las actualizaciones (una actualización en un nodo entra en conflicto con una actualización o eliminación en otro nodo), hay otros tipos de conflictos. Cada tipo de conflicto descrito en esta sección puede producirse durante la fase de carga o la fase de descarga del procesamiento de mezcla. El procesamiento de carga es la primera reconciliación de los cambios realizados en una sesión de mezcla concreta, y es la fase durante la cual el agente de mezcla replica los cambios del suscriptor al publicador. Los conflictos detectados durante este procesamiento se conocen como conflictos de carga. El procesamiento de la descarga implica mover los cambios del publicador al suscriptor y se produce después del procesamiento de la carga. Los conflictos durante esta fase de procesamiento se conocen como conflictos de descarga.

Para obtener más información sobre los tipos de conflictos, consulte MSmerge_conflicts_info, especialmente las conflict_type columnas y reason_code .

Conflictos de actualización-actualización

El agente de mezcla detecta conflictos de actualización-actualización cuando una actualización de una fila (o columna, o registro lógico) en un nodo entra en conflicto con otra actualización de la misma fila en otro nodo. El comportamiento del solucionador predeterminado en este caso es enviar la versión ganadora de la fila al nodo que pierde y registrar la versión de fila que pierde en la tabla de conflictos del artículo.

Conflictos de actualización y eliminación

El Agente de mezcla detecta conflictos de actualización-eliminación cuando una actualización de datos en un nodo entra en conflicto con una eliminación en otro nodo. En este caso, el Agente de mezcla actualiza una fila; sin embargo, cuando el Agente de mezcla busca esa fila en el destino, no puede encontrar la fila porque se eliminó. Si el nodo ganador es el que actualizó la fila, se descarta la operación de eliminación en el nodo perdedor y el Agente de mezcla envía la fila recién actualizada al perdedor del conflicto. El agente de mezcla registra información sobre la versión perdida de la fila en la tabla MSmerge_conflicts_info.

Conflictos de cambios fallidos

El Agente de mezcla genera estos conflictos cuando no puede aplicar un cambio determinado. Esto suele ocurrir debido a una diferencia en las definiciones de restricción entre el publicador y el suscriptor, y el uso de la NOT FOR REPLICATION propiedad (NFR) en la restricción. Algunos ejemplos son:

  • Un conflicto de clave externa en el suscriptor, que puede producirse cuando la restricción del lado del suscriptor no está marcada como NFR.

  • Diferencias en las restricciones entre el publicador y los suscriptores, y las restricciones no están marcadas como NFR.

  • Falta de disponibilidad de objetos dependientes en el suscriptor. Por ejemplo, si publica una vista, pero no la tabla de la que depende dicha vista, se producirá un error si intenta insertar a través de esa vista en el suscriptor.

  • Agrega una lógica de filtrado para una publicación que no coincide con las restricciones de clave principal y clave externa. Los conflictos pueden producirse cuando el motor relacional de SQL Server intenta respetar una restricción, pero el Agente de mezcla respeta la definición del filtro de combinación entre los artículos. El Agente de mezcla no puede aplicar el cambio en el nodo de destino debido a las restricciones de nivel de tabla, lo que produce un conflicto.

  • Los conflictos debido a violaciones de índices únicos, restricciones únicas o claves primarias pueden ocurrir si se definen columnas de identidad para el artículo y no se utiliza la gestión automatizada de identidades. Esto puede ser un problema si dos suscriptores usaran el mismo valor de identidad para una fila recién insertada. Para obtener más información sobre la administración de intervalos de identidades, consulte Replicación de columnas de identidad.

  • Conflictos debidos a la lógica de activación que impide al agente de mezcla insertar una fila en la tabla de destino. Considere un desencadenador de actualización definido en el suscriptor; el desencadenador no está marcado como NFR e incluye un ROLLBACK en su lógica. Si se produce un error, el desencadenador emite un ROLLBACK de la transacción, lo que hace que el agente de mezcla detecte un conflicto de cambio fallido.

Contenido relacionado

  • Last updated on