Compartir a través de

Detección y resolución de conflictos de actualización en cola

Dado que las suscripciones de actualización en cola permiten modificaciones en los mismos datos en varias ubicaciones, puede haber conflictos cuando los datos se sincronizan en el publicador. La replicación detecta los conflictos cuando los cambios se sincronizan con el publicador y resuelve esos conflictos mediante la directiva de resolución seleccionada al crear la publicación. Pueden producirse los siguientes conflictos:

  • Actualizar e insertar conflictos. Este conflicto se produce cuando se cambian los mismos datos en dos ubicaciones. Un cambio gana y el otro pierde.

  • Eliminar conflictos. Este conflicto se produce cuando se elimina la misma fila en una ubicación y se cambia en la otra.

La detección y resolución de conflictos pueden ser un proceso lento y intensivo de recursos; por lo tanto, es mejor minimizar los conflictos en la aplicación mediante la creación de particiones de datos para que los distintos suscriptores modifiquen diferentes subconjuntos de datos.

Detección de conflictos

Al crear una publicación y habilitar la actualización en cola, la replicación agrega una columna uniqueidentifier (msrepl_tran_version) con el valor predeterminado de newid() a la tabla subyacente. Cuando se cambian los datos publicados en el publicador o en el suscriptor, la fila recibe un nuevo identificador único global (GUID) para indicar que existe una nueva versión de fila. El Agente de lectura de cola usa esta columna durante la sincronización para determinar si existe un conflicto.

Una transacción en una cola almacena los valores de las versiones de filas, tanto antiguas como nuevas. Cuando se aplica la transacción en el publicador, se comparan los GUID de la transacción y el GUID de la publicación. Si el GUID anterior almacenado en la transacción coincide con el GUID de la publicación, la publicación se actualiza y a la fila se le asigna el nuevo GUID generado por el suscriptor. Al actualizar la publicación con el GUID de la transacción, se obtienen versiones de fila coincidentes en la publicación y en la transacción.

Si el GUID antiguo almacenado en la transacción no coincide con el GUID de la publicación, se detecta un conflicto. El nuevo GUID de la publicación indica que existen dos versiones de fila diferentes: una en la transacción enviada por el suscriptor y otra más reciente que existe en el publicador. En este caso, otro suscriptor o el publicador actualizaron la misma fila de la publicación antes de que se sincronizó esta transacción del suscriptor.

A diferencia de la replicación de mezcla, el uso de una columna GUID no se usa para identificar la propia fila, pero se usa para comprobar si la fila ha cambiado.

Resolución de conflictos

Cuando creas una publicación usando la actualización en cola, seleccionas un solucionador de conflictos que se utilizará si se detecta algún conflicto. El solucionador de conflictos rige cómo el Agente de lectura de cola controla las distintas versiones de la misma fila encontradas durante la sincronización. Puede cambiar la directiva de resolución de conflictos después de crear la publicación siempre que no haya suscripciones a la publicación. Las opciones de resolución de conflictos son las siguientes:

  • Publisher gana (el valor predeterminado)

  • Publisher gana y la suscripción se reinicializa

  • El suscriptor gana

Los conflictos se registran y se pueden ver mediante el Visor de conflictos.

Para establecer la directiva de resolución de conflictos de actualización en cola

Para ver conflictos de datos

Las ganancias del editor

Cuando la resolución de conflictos se establece en "El Publisher gana", la coherencia transaccional se mantiene en función de los datos del Publisher. La transacción en conflicto se revierte en el suscriptor que la inició.

El Agente lector de la cola detecta un conflicto y los comandos de compensación se generan y propagan al Suscriptor mediante su publicación en la base de datos de distribución. A continuación, el Agente de distribución aplica los comandos de compensación al suscriptor que originó la transacción en conflicto. Las acciones de compensación actualizan las filas del suscriptor para que coincidan con las filas del publicador.

Hasta que se apliquen los comandos de compensación, es posible leer los resultados de una transacción que finalmente se revertirá en el suscriptor. Esto equivale a una lectura sucia (lectura sin confirmar nivel de aislamiento). No hay ninguna compensación por las transacciones dependientes posteriores que se pueden producir. Sin embargo, se respetan los límites de transacción y todas las acciones dentro de una transacción se confirman o, en el caso de un conflicto, se revierten.

El publicador gana y la suscripción se reinicializa

Reinicializar el suscriptor para resolver conflictos mantiene una coherencia transaccional estricta en el suscriptor, pero puede llevar mucho tiempo si la publicación contiene grandes cantidades de datos.

Cuando el Agente de lectura de cola detecta un conflicto, se rechazan todas las transacciones restantes de la cola (incluida la transacción en conflicto) y el suscriptor está marcado para reinicialización. El Agente de Distribución aplica al suscriptor la próxima instantánea generada para la publicación.

Gana el suscriptor

La detección de conflictos bajo la política de "gana el Suscriptor" significa que la última transacción del Suscriptor en actualizar al Publicador prevalece. En este caso, cuando se detecta un conflicto, se sigue usando la transacción enviada por el Suscriptor y se actualiza el Publicador. Esta directiva es adecuada para las aplicaciones en las que estos cambios no ponen en peligro la integridad de los datos.

Véase también

Suscripciones actualizables para la replicación transaccional

  • Last updated on