Detección de conflictos en la replicación punto a punto
Se aplica a:
SQL Server
La replicación transaccional punto a punto permite insertar, actualizar o eliminar datos en cualquier nodo de una topología y propagar los cambios de los datos a los demás nodos. Dado que se pueden cambiar los datos de cualquier nodo, podrían producirse conflictos entre los datos modificados en los distintos nodos. Si una fila se modifica en más de un nodo, puede producirse un conflicto o incluso la pérdida de una actualización cuando la fila se propaga a otros nodos.
La replicación punto a punto ofrece la opción de habilitar la detección de conflictos en una topología punto a punto. Esta opción ayuda a evitar problemas que se producen por conflictos no detectados, como comportamientos incoherentes de las aplicaciones y actualizaciones perdidas. Cuando se habilita esta opción, de forma predeterminada, un cambio conflictivo se trata como un error crítico que produce el error del Agente de distribución. En caso de conflicto, la topología permanece en un estado incoherente hasta que se resuelve el conflicto y se restablece la coherencia de los datos en toda la topología.
Nota:
Para evitar la posible incoherencia de datos, asegúrese de evitar los conflictos en una topología punto a punto, incluso con la detección de conflictos habilitada. Para asegurarse de que las operaciones de escritura para una fila determinada se realizan en un solo nodo, las aplicaciones que tienen acceso y cambian datos deben particionar las operaciones de inserción, actualización y eliminación. Este particionamiento asegura que las modificaciones introducidas en una fila determinada que se originan en un nodo se sincronizan con todos los demás nodos de la topología antes de que se modifique la fila en otro nodo. Si una aplicación requiere funcionalidades sofisticadas de detección y resolución de conflictos, use la replicación de mezcla. Para obtener más información, consulte Replicación de mezcla y Detectar y solucionar conflictos de replicación de mezcla.
Descripción de los conflictos y de la detección de conflictos
En una única base de datos, los cambios realizados en la misma fila por parte de aplicaciones diferentes no provocan conflictos. Esto se debe a que las transacciones se serializan, y los bloqueos controlan los cambios simultáneos. En un sistema distribuido asincrónico, como en uno de replicación punto a punto, las transacciones se producen de forma independiente en cada nodo, y no hay ningún mecanismo para serializarlas por los distintos nodos. Se podría usar una confirmación en dos fases de tipo protocolo, pero esto afecta de forma significativa al rendimiento.
En sistemas como la replicación punto a punto, los conflictos no se detectan cuando los cambios se confirman en cada uno de los nodos del mismo nivel. En su lugar, se detectan al replicar los cambios y aplicarlos a los demás nodos del mismo nivel. En la replicación punto a punto, los conflictos se detectan mediante los procedimientos almacenados que aplican los cambios a cada nodo, basándose en una o varias columnas ocultas de cada tabla publicada.
Antes de SQL Server 2019 (15.x) CU13, SQL Server agrega una columna oculta a cada tabla publicada: $sys_p2p_cd_id. En esta columna oculta, se almacena un identificador que combina la versión de la fila con un identificador de originador que se especifica para cada nodo.
En SQL Server 2019 (15.x) CU13 y versiones posteriores, si crea la publicación punto a punto con @p2p_conflictdetection_policy = 'lastwriter', SQL Server agrega una columna oculta adicional a cada tabla publicada: $sys_md_cd_id. Esta columna oculta almacena datetime como un tipo de datos datetime2.
Durante la sincronización, el Agente de distribución ejecuta los procedimientos para cada tabla. Estos procedimientos aplican las operaciones de inserción, actualización y eliminación procedentes de los demás nodos del mismo nivel. Si uno de los procedimientos detecta un conflicto cuando lee el valor o los valores de la columna oculta, genera el error 22815 que tiene un nivel de gravedad de 16:
A conflict of type '%s' was detected at peer %d between peer %d (incoming), transaction id %s and peer %d (on disk), transaction id %s
Este error hace que, de forma predeterminada, el Agente de distribución deje de aplicar cambios a ese nodo. Para obtener información sobre cómo tratar los conflictos detectados, vea Controlar los conflictos.
Nota:
Solo pueden tener acceso a la columna oculta los usuarios que hayan iniciado una sesión a través de la conexión de administrador dedicada (DAC). Para obtener más información sobre DAC, vea Conexión de diagnóstico para administradores de bases de datos.
La replicación punto a punto detecta los tipos de conflictos siguientes:
Inserción-inserción
Todas las filas de cada tabla que participa en una replicación punto a punto se identifican de forma exclusiva mediante valores de clave principal. Se produce un conflicto de inserción-inserción al insertar una fila con el mismo valor de clave en más de un nodo.
Actualización-actualización
Se produce cuando se actualiza la misma fila en más de un nodo.
Inserción-actualización
Se produce cuando se actualiza una fila en un nodo, pero la misma fila se ha eliminado y, a continuación, se ha vuelto a insertar en otro nodo.
Inserción-eliminación
Se produce cuando se elimina una fila en un nodo, pero la misma fila se ha eliminado y, a continuación, se ha vuelto a insertar en otro nodo.
Actualización-eliminación
Se produce cuando se actualiza una fila en un nodo, pero la misma fila se ha eliminado en otro nodo.
Eliminación-eliminación
Se produce cuando se elimina una fila en más de un nodo.
Habilitar la detección de conflictos
Para usar la detección de conflictos, habilite la detección para todos los nodos. De forma predeterminada, la detección de conflictos se habilita al configurar la replicación punto a punto en SQL Server Management Studio. Se recomienda tener habilitada la detección, incluso en escenarios en los que no se espere ningún conflicto. La detección de conflictos se puede habilitar y deshabilitar utilizando Management Studio o procedimientos almacenados de Transact-SQL:
Puede habilitar y deshabilitar la detección en mediante la página Opciones de suscripción del cuadro de diálogo Propiedades de la publicación o con la página Configurar topología del Asistente de configuración de la topología punto a punto.
Si configura la detección de conflictos mediante Management Studio, el Agente de distribución se configura para que deje de aplicar cambios cuando se detecte un conflicto.
También puede habilitar y deshabilitar la detección con los procedimientos almacenados siguientes:
sp_configure_peerconflictdetection.
Si configura la detección de conflictos mediante procedimientos almacenados, puede especificar si el Agente de distribución debe dejar de aplicar cambios cuando se detecte un conflicto. La configuración predeterminada hace que el agente se detenga. Se recomienda utilizar la configuración predeterminada.
Controlar los conflictos
Cuando se produce un conflicto en la replicación punto a punto, se genera la alerta de detección de conflictos punto a punto. Configure esta alerta para que se notifique la existencia de conflictos. Para obtener más información sobre las alertas, vea Usar alertas para eventos del Agente de replicación.
Una vez que se detenga el Agente de distribución y se genere la alerta, use uno de los métodos siguientes para controlar los conflictos existentes:
Reinicialice el nodo en el que se detectó el conflicto a partir de la copia de seguridad de un nodo que contenga los datos necesarios (este es el enfoque recomendado). Este método garantiza que los datos sean coherentes.
Intente sincronizar de nuevo el nodo permitiendo que el Agente de distribución continúe aplicando los cambios:
Ejecute sp_changepublication: especifique "p2p_continue_onconflict" para el parámetro @property y true para el parámetro @value.
Reinicie el Agente de distribución.
Use el visor de conflictos para comprobar los conflictos detectados y determine las filas afectadas, el tipo de conflicto y la fila ganadora. El conflicto se resuelve en función del valor del identificador de originador que se especificó durante la configuración: la fila procedente del nodo con el identificador más alto gana el conflicto. Para obtener más información, consulte Ver conflictos de datos para publicaciones transaccionales (SQL Server Management Studio).
Ejecute la validación para asegurarse de que las filas en conflicto convergieron correctamente. Para obtener más información, vea Validar datos replicados.
Nota:
Si los datos son incoherentes después de este paso, debe actualizar manualmente las filas en el nodo que tenga la prioridad más alta y, a continuación, dejar que se propaguen los cambios desde ese nodo. Si no hay ningún otro conflicto relacionado con los cambios en la topología, todos los nodos se encontrarán en un estado coherente.
Ejecute sp_changepublication: especifique "p2p_continue_onconflict" para el parámetro @property y false para el parámetro @value.
Control automático de conflictos con los últimos casos de escritura correcta
A partir de SQL Server 2019 (15.x) CU13, puede configurar la replicación punto a punto para resolver automáticamente los conflictos permitiendo la inserción o la actualización más recientes a fin de ganar el conflicto. Si alguna de las escrituras elimina la fila, SQL Server permite que la eliminación corrija el conflicto. Este método se conoce como "últimos casos de escritura correcta".
Siga procedimientos almacenados para configurar los últimos casos de escritura correcta. Vea Configuración de la detección y la resolución de conflictos del último objeto de escritura. No se pueden configurar los últimos casos de escritura correcta con SQL Server Management Studio.
Nota:
La replicación punto a punto con Últimos casos de escritura correcta depende de que los relojes de los nodos participantes se sincronicen para obtener resultados confiables. Si los relojes de los servidores participantes están demasiado desincronizados, el resultado de una resolución de conflictos puede ser inesperado o no deseado. Por ejemplo, si el servidor A tiene un reloj preciso, pero el servidor B tiene una semana de retraso, se elegirá el servidor A para resolver todos los conflictos, incluso si realmente no fue el último en actualizar la fila. Si no es posible mantener los relojes dentro de la tolerancia que necesita para la resolución de los resultados, puede elegir una estrategia de resolución de conflictos diferente.
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de