Aspectos a tener en cuenta en una topología de republicación…
…en particular cuando mezclamos replicación transaccional y de mezcla. Veamos el siguiente entorno:
Servidor 1: Publicación transaccional.
Servidor 2: Subscrito a la publicación transaccional y con una publicación de mezcla sobre estas mismas tablas.
Servidor 3 (o máquina cliente): subscrito a la publicación de mezcla.
El primer aspecto a tener en cuenta, es la gestión de cambios en el servidor 3: Hay que tener en cuenta que por defecto, la replicación de mezcla va a sincronizar los cambios en las dos direcciones y la replicación transaccional sólo en una de ellas.
Por lo tanto la primera decisión a tomar es la posibilidad o no de realizar cambios en el servidor 3:
-Si optamos por permitir estos cambios, deberemos modificar la replicación transaccional para que permita cambios en el subscriptor (Subscripciones actualizables para replicación transaccional)
-Si optamos por no permitir estos cambios, lo mejor es modificar la publicación de mezcla para que sean artículos sólo de descarga
En la primera opción, conviene replantearse la topología, ya que si los cambios van a ser muy frecuentes, probablemente sea más eficiente una publicación de mezcla entre el Servidor 1 y el 2.
En el caso contrario (modificaciones sólo en la dirección 1->2->3), sin embargo, puede convenirnos mantener la topología ¿Por qué mantener la publicación del servidor 2 como publicación de mezcla? Es posible que el servidor (o servidores) 3 sea un cliente con conectividad limitada (por ejemplo, sólo podría sincronizar una vez al día). En situaciones en las que no tenemos sincronización frecuente la replicación de mezcla es más eficiente.
El siguiente aspecto a tener en cuenta, es incluir el parámetro “@published_in_tran_pub=’true’” en los artículos de la publicación de mezcla. Si este parámetro no se incluye, los cambios que provengan del distribuidor de la publicación transaccional no se detectarán (serán interpretados con origen en el subscriptor de mezcla) y por lo tanto no se replicarán.
La causa de que no se repliquen los datos la encontramos en la lógica de los triggers. Sin ningún parámetro adicional en el artículo, el trigger incluye la siguiente sintaxis:
Que evita que se detecten como cambios a replicar los que provienen del subscriptor. Como vemos, esta lógica marca como pertenecientes a la topología merge cualquier agente de réplica.
Una vez modificado el artículo con la propiedad, observamos que esta línea ha cambiado por:
En este caso, aparece una lógica más compleja que no identificará como perteneciente a la topología de mezcla los cambios que provienen de otros agentes de replicación, y por lo tanto se incluirán estos cambios en la siguiente sincronización.
Raquel Vicente de la Rosa
Ingeniero de Soporte de SQL Server