sql server - replicacion - ¿Cómo se mantienen sincronizados dos sistemas relacionados pero separados?

replicacion sql server 2008 paso a paso (5)

Mi proyecto de desarrollo actual tiene dos aspectos. Primero, hay un sitio web público donde los usuarios externos pueden enviar y actualizar información para varios propósitos. Esta información luego se guarda en un servidor SQL local en la instalación de colo.

El segundo aspecto es una aplicación interna que los empleados utilizan para administrar esos mismos registros (conceptualmente) y proporcionan actualizaciones de estado, aprobaciones, etc. Esta aplicación se aloja dentro del firewall corporativo con su propia base de datos local de SQL Server.

Las dos redes están conectadas por una solución de VPN de hardware, que es decente, pero obviamente no es la más rápida del mundo.

Las dos bases de datos son similares y comparten muchas de las mismas tablas, pero no son 100% iguales. Muchas de las tablas en ambos lados son muy específicas para la aplicación interna o externa.

Entonces la pregunta es: cuando un usuario actualiza su información o envía un registro en el sitio web público, ¿cómo transfiere esos datos a la base de datos de la aplicación interna para que pueda ser administrada por el personal interno? Y viceversa ... ¿Cómo llevas las actualizaciones hechas por el personal al sitio web?

Vale la pena mencionar que mientras más "tiempo real" ocurran estas actualizaciones, mejor. No es que tenga que ser instantáneo, simplemente razonablemente rápido.

Hasta ahora, he pensado en usar los siguientes tipos de enfoques:

Replicación bidireccional
El servicio web interactúa en ambos lados con el código para sincronizar los cambios a medida que se realizan (en tiempo real).
El servicio web interactúa en ambos lados con el código para sincronizar de forma asíncrona los cambios (utilizando un mecanismo de puesta en cola).

¿Algún consejo? ¿Alguien que haya tenido el mismo problema? ¿Se te ocurrió una solución que funcionó bien para ti?

Diría que simplemente tengo un trabajo que copia los datos en la tabla de entrada de la base de datos de pub en una tabla pendiente de la base de datos privada. Luego, una vez que actualices los datos en el lado privado, haz que se repliquen en el lado público. Si no tiene actualizada la información replicada del lado público, debería ser una solución de replicación transaccional bastante sencilla.

Tenemos una tienda como cliente, con tres tiendas conectadas a la misma VPN
Dos de las tiendas tienen una computadora que funciona como un "servidor" para esa tienda y la tercera tiene la "base de datos maestra"
Para sincronizar todo con el maestro, no tenemos la mejor solución, pero funciona: hay una PC dedicada que ejecuta una aplicación que verifica la marca de tiempo de cada registro en cada tabla de las dos tiendas y si es diferente la última vez sincronizas, copia los resultados
Tenga en cuenta que esto funciona en ambos sentidos. Es decir, si actualiza un producto en la base de datos maestra, este cambio se propagará a las otras dos tiendas. Si tiene un nuevo pedido en una de las tiendas, se transmitirá al "maestro".
Con algunas optimizaciones puede hacer que todas las tiendas se sincronicen en alrededor de 20 minutos

Recientemente, he tenido mucho éxito con SQL Server Service Broker, que ofrece mensajería asíncrona confiable y persistente lista para usar con muy poco esfuerzo de implementación.

Es rápido de configurar y, a medida que aprende más, puede usar algunas de las características más avanzadas.
Desconocido para la mayoría, también es parte de las ediciones de escritorio, por lo que se puede utilizar como un sistema de mensajería de la estación de trabajo
Si tiene habilidades de T-SQL existentes, se pueden aprovechar ya que todo el código para leer y escribir se hace en SQL
Es deslumbrantemente rápido

Es una parte muy poco publicitada de SQL Server y vale la pena echarle un vistazo.

Estoy a mitad de camino en un proyecto similar, excepto que tengo varios sitios que necesitan sincronizarse a través de conexiones lentas (de acceso telefónico en algunos casos).

Primero necesitas rastrear los cambios, si puedes usar SQL 2008 (incluso la versión Express es suficiente si el límite de 2Gb no es un problema) esto aliviará mucho el dolor, solo activa Change Tracking en la base de datos y en cada tabla. Estamos utilizando SQL Server 2008 en la oficina central con el esquema extendido y SQL Express 2008 en cada sitio con un subconjunto de datos y un esquema limitado.

En segundo lugar, necesita hacer un seguimiento de sus cambios, Sync Services hace el truco muy bien y admite el uso de una entrada WCF en la base de datos principal. En este ejemplo, necesitará utilizar la sincronización mediante el uso del ejemplo de SQL Express Client como punto de partida, tenga en cuenta que está basado en SQL 2005, por lo que deberá actualizarlo para aprovechar las funciones de Seguimiento de cambios en 2008. Por defecto, Sync Services usa SQL CE en los clientes, y estoy seguro de que no es suficiente en su caso. Necesitará un servicio que se ejecute periódicamente en su servidor web (puede ser tan frecuente como cada 10 segundos si lo desea) ejecuta el método Synchronize (). Esto le indicará a su base de datos principal los cambios realizados localmente y luego le preguntará al servidor por todos los cambios realizados allí. Puede configurar get y aplicar código SQL para llamar a procedimientos almacenados y puede agregar controladores de eventos para manejar conflictos (por ejemplo, actualización de cliente vs actualización de servidor) y resolverlos en consecuencia en cada extremo.

Este es un escenario de integración bastante común, creo. Personalmente, creo que una solución de mensajería asíncrona que utiliza una cola es ideal.

Debería poder lograr la sincronización casi en tiempo real sin la sobrecarga o la complejidad de algo así como la replicación.

Los servicios web sincrónicos no son ideales porque su código tendrá que ser muy sofisticado para manejar escenarios de falla. ¿Qué sucede cuando se reinicia un sistema mientras que el otro continúa publicando cambios? ¿El sistema de envío obtiene tiempos de espera? ¿Qué hace con esos? A menos que esté preparado para perder datos, querrá algún tipo de cola transaccional (como MSMQ) para recibir los avisos de cambio y asegurarse de que lleguen al otro sistema. Si cualquiera de los sistemas falla, los cambios (pasados como mensajes) simplemente se acumularán y tan pronto como se establezca una conexión, el servidor de reinicio procesará todos los mensajes en cola y se pondrá al día, haciendo que la integridad del sistema sea mucho, mucho más fácil de lograr.

Existen algunas herramientas de código abierto que pueden hacer que esto sea más fácil para usted si usa .NET (especialmente si desea usar MSMQ).

nServiceBus por Udi Dahan
Tránsito masivo por Dru Sellers y Chris Patterson

También hay productos comerciales, y si está considerando una opción comercial, consulte aquí una lista de opciones en .NET. Por supuesto, WCF puede hacer mensajes asincrónicos utilizando enlaces MSMQ, pero una herramienta como nServiceBus o MassTransit le proporcionará una API Send / Receive o Pub / Sub muy simple que hará que su requerimiento sea un trabajo muy sencillo.

Si está utilizando Java, hay muchas implementaciones de bus de servicio de código abierto que harán que este tipo de mensajería asincrónica bidireccional sea muy fácil, como Mule o quizás solo ActiveMQ.

También puede considerar leer el blog de Udi Dahan , escuchando algunos de sus podcasts. Aquí hay algunos más buenos recursos para comenzar.