esperar a que la replicación transaccional en ADO.NET o TSQL

Question

Mi aplicación web utiliza ADO.NET contra la base de datos de SQL Server 2008. escribe suceda en contra de una base de datos primaria (editor), pero lee se equilibra la carga a través del primario y una base de datos secundaria (abonado). Utilizamos incorporada en la replicación transaccional de SQL Server para mantener la fecha hasta a la secundaria. La mayor parte del tiempo, el par de segundos de latencia no es un problema.

Sin embargo, tengo un caso en el que me gustaría para bloquear hasta que la transacción se confirma en el sitio secundario. El bloqueo durante unos segundos está bien, pero el retorno de una página a rancio que el usuario no lo es. ¿Hay alguna manera en ADO.NET o TSQL para especificar que quiero esperar a que la replicación para completar? O puedo, de la editorial, comprobar el estado de la replicación de la transacción sin necesidad de conectarse manualmente al servidor secundario.

[editar] 99,9% del tiempo, los datos en el suscriptor es "suficientemente fresco". Pero hay una operación que lo invalida. No puedo leer desde el editor cada vez que en la remota posibilidad de que se ha convertido en no válido. Si no puedo resolver este problema bajo la replicación transaccional, puede sugerir una arquitectura alternativa?

Answer 1

No hay tal solución para SQL Server, pero así es como he trabajado alrededor de él en otros entornos.

Utilice tres cadenas de conexión por separado en su aplicación, y elegir el más adecuado en función de las necesidades de su consulta:

• en tiempo real - apuntando directamente al servidor de un maestro. Todas las escrituras van a esta cadena de conexión, y sólo lee la mayor parte de misión crítica ir aquí.
• casi en tiempo real - Puntos en una piscina de equilibrio de carga de los abonados. No hay escrituras van aquí, sólo lee. Se utiliza para la gran mayoría de OLTP lee.
• Retraso de informes - En su entorno en este momento, que va a apuntar a la misma agrupación de equilibrio de carga de los abonados, pero en el camino se puede utilizar una tecnología como el trasvase de registros para tener un grupo de servidores 8-24 horas atrás. Estos escalar muy bien, pero los datos de muy atrás. Es muy bueno para la presentación de informes, la búsqueda, la historia a largo plazo, y otras necesidades en tiempo no real.

Si el diseño de su aplicación para utilizar las 3 cadenas de conexión desde el principio, la escala es mucho más fácil, especialmente en el caso de que esté experimentando.

Answer 2

Se está describiendo una situación mirroring síncrono. La replicación no se puede, por definición, el apoyo a su requerimiento. Replicación debe esperar a que una transacción se comprometa antes de leerlo desde el registro y la entrega a la distribuidora y de allí al abonado, lo que significa que la replicación, por definición, tiene una ventana de oportunidad para que los datos sean de sincronización.

Si usted tiene un requisito de una operación para leer la copia authorithative de los datos, entonces usted debe hacer que decission en el cliente y garantizar que lea de la editorial en ese caso.

Si bien se puede, en threory, validar wether una determinada transacción se distribuyó al abonado o no, usted no debe basar su diseño en él. La replicación transaccional no hace ninguna garantía de latencia, por diseño, por lo que no se puede confiar en un modo de funcionamiento 'día perfecto'.