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

Al crear una suscripción, además de especificar si se trata de una suscripción de extracción o de inserción, es preciso indicar si es una suscripción de servidor o de cliente; una vez creada la suscripción, el tipo no se puede cambiar (en versiones anteriores de Microsoft SQL Server, las suscripciones de cliente y de servidor se denominaban suscripciones locales y globales, respectivamente).

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

Si se cambia una fila en una suscripción de cliente, no se asigna ninguna prioridad al cambio hasta que la suscripción se sincroniza. Durante la sincronización, a los cambios del suscriptor se les asigna la prioridad del publicador y conservan dicha prioridad para 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 determinadas.

Cuando se cambia una fila en una suscripción de servidor, la prioridad de suscripción se almacena en los metadatos del cambio. Este valor de prioridad viaja con la fila modificada cuando se mezcla con los cambios de otros suscriptores. Esto garantiza que un cambio realizado por una suscripción de prioridad superior no pierda frente a un cambio posterior realizado por una suscripción con prioridad inferior.

Una suscripción no puede tener un valor de prioridad explícito que sea superior al de su publicador. El publicador de nivel superior en una topología de replicación de mezcla tiene siempre un valor de prioridad explícito de 100,00. Todas las suscripciones a dicha publicación deben tener un valor de prioridad inferior a ese valor. En una topología de republicación:

• Si el suscriptor va a republicar datos, la suscripción debe ser una suscripción de servidor con un valor de prioridad inferior al del publicador que se encuentra por encima del suscriptor.

• Si el suscriptor no va a republicar datos (porque se encuentra en el nivel de hoja del árbol de republicación), la suscripción debe ser una suscripción de cliente.

Para obtener más información acerca de las suscripciones de servidor y las propiedades, vea Ejemplo de resolución de conflicto de mezcla basada en el tipo de suscripción y las prioridades asignadas.

Notificación diferida de conflictos

El que un cambio de datos se convierta o no en un conflicto depende del tipo de seguimiento de conflictos establecido para el artículo: por filas, columnas o registros lógicos. Para obtener más información acerca del seguimiento por registros lógicos, vea Detectar y resolver conflictos en registros lógicos.

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

Para el seguimiento por filas y el seguimiento por columnas, la resolución del conflicto es la misma: la fila de datos completa se sobrescribe con los datos del ganador del conflicto (para el seguimiento por registros lógicos, la resolución depende de la propiedad del artículo logical_record_level_conflict_resolution).

La semántica de la aplicación determina normalmente la opción de seguimiento que se debe utilizar. Por ejemplo, si está actualizando datos de clientes que suelen incluirse al mismo tiempo, como una dirección y un número de teléfono, es recomendable elegir el seguimiento por filas. Si se eligiera el seguimiento por columnas en esta situación, los cambios realizados en la dirección del cliente en una ubicación y en el número de teléfono del cliente en otra ubicación no se detectarían como un conflicto: los datos se mezclarían en la sincronización y el error pasaría desapercibido. En otras situaciones, la actualización de columnas individuales en sitios diferentes puede ser la opción más lógica. Por ejemplo, dos sitios pueden tener acceso a diferentes tipos de información estadística sobre un cliente, como el nivel de ingresos y la cantidad total en dólares de las compras realizadas con la tarjeta de crédito. Si selecciona el seguimiento por columnas se asegurará de que ambos sitios pueden incluir datos estadísticos para diferentes columnas sin generar conflictos innecesarios.

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

El Agente de mezcla detecta los conflictos de eliminación-actualización cuando una actualización de los datos de un nodo entra en conflicto con una eliminación en otro. En este caso, el Agente de mezcla actualiza una fila; no obstante, cuando el Agente de mezcla busca esa fila en el destino, no la encuentra porque ha sido eliminada. Si el ganador es el nodo que actualizó la fila, la eliminación en el nodo perdedor se descarta y el Agente de mezcla envía la fila recién actualizada al perdedor del conflicto. El Agente de mezcla registra información acerca de la versión perdedora de la fila en la tabla MSmerge_conflicts_info.

El Agente de mezcla produce estos conflictos cuando no puede aplicar un cambio determinado. Esto normalmente sucede debido a una diferencia en las definiciones de restricciones entre el publicador y el suscriptor, y al uso de la propiedad NOT FOR REPLICATION (NFR) en la restricción. Los ejemplos incluyen:

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

• Diferencias en las restricciones entre el publicador y los suscriptores, y las mismas 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, se producirá un error al intentar realizar una inserción en el suscriptor a través de dicha vista.

• La lógica del filtro de combinación de una publicación que no se corresponde 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 está respetando 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 da lugar a un conflicto.

• Pueden surgir conflictos debido a infracciones de índice único o de restricción única si se definen columnas de identidad para el artículo y no se utiliza la administración automatizada de identidades. Esto puede representar un problema si dos suscriptores utilizaran el mismo valor de identidad para una fila recién insertada. Para obtener más información acerca de la administración de intervalos de identidad, vea Replicar columnas de identidad.

• Conflictos debidos a que la lógica del desencadenador impide que el Agente de mezcla inserte una fila en la tabla de destino. Piense en un desencadenador de actualización definido en el suscriptor; el desencadenador no está marcado como NFR e incluye la instrucción ROLLBACK en su lógica. Si se produce un error, el desencadenador emite una instrucción ROLLBACK para revertir la transacción, lo que provoca que el Agente de mezcla detecte un conflicto de cambio con error.