Cuando pensamos en replicación de datos es habitual que tengamos una fuerte tendencia a pensar en los modelos tradicionales de replicación. Por ejemplo aquellos que se ofrecen como ejemplos de uso “típicos” de cada uno de los “sabores” de la replicación. Si pensamos en una replicación de mezcla normalmente lo que nos viene a la mente es un escenario donde existen un conjunto de dispositivos móviles, portátiles, PDAs, teléfonos inteligentes, etc. que sincronizan sus bases de datos locales contra un servidor central. Estos últimos años vemos como existe una tendencia muy marcada a la centralización de los datos en entornos Cloud.

Uno de los inconvenientes de estas centralizaciones es que la infraestructura de comunicaciones se vuelve totalmente crítica siendo muy difícil (imposible la mayoría de veces) el poder trabajar de forma “offline”. Es posible que tengamos una aplicación magnífica pero dependiente de las aún inestables infraestructuras de acceso a internet mediante tecnología móvil. En el caso de una replicación de mezcla disponemos de una copia local de los datos con los que la aplicación puede trabajar de forma natural quedando la sincronización con el servidor central pendiente a que la conexión con éste sea posible.Si por ejemplo pensamos en una replicación P2P nos viene a la mente la distribución de datos entre CPDs situados a miles de kilómetros de distancia con usuarios distribuidos geográficamente y conectando cada uno al nodo más cercano geográficamente. No hay nada de malo en tener claro estos ejemplos como casos de uso en los cuales un tipo de réplica puede ser apropiada pero no deberemos por ello cerrarnos a ofrecer soluciones distintas siempre que conozcamos que los requerimientos están cubiertos con un “sabor” de la replicación. Otro caso de uso menos frecuente de P2P es el de la escalabilidad horizontal dentro de un mismo CPD donde varias instancias replicadas P2P forman un pool de servidores común para distribuir la carga de las aplicaciones.

Otro ejemplo de estas arquitecturas menos habituales es por ejemplo la sincronización de dos modelos de datos distintos entre dos servidores distintos. Este escenario surge habitualmente cuando se requiere de la integración de sistemas de distintos fabricantes y no es viable, por latencias, etc. el realizar importaciones/exportaciones cruzadas diarias, semanales, etc. Básicamente lo que el cliente desearía sería un “meta modelo” de base de datos que fuese compatible con ambas aplicaciones simultáneamente. De hecho, esa es una posible solución con vistas siempre que los proveedores permitan realizar cambios de tanto calado en el modelo de datos:

Arquitecturas de replicación

 

En los casos en los que no es aceptable este tipo de cambios, podemos optar por soluciones menos agresivas. Por ejemplo podemos utilizar una réplica transaccional bidireccional con procedimientos almacenados personalizados. Básicamente tendríamos dos publicaciones, una en el sistema A a la que estaría subscrito el sistema B y otra en el sistema B a la que estaría subscrito el sistema A. Estas publicaciones replicarían los cambios sobre las distintas entidades del modelo ejecutando procedimientos almacenados en el subscriptor. De esta forma podemos personalizar las acciones necesarias a realizar por ejemplo en el caso de insertar un cliente nuevo del sistema B cuando llegue en forma de inserción replicada al sistema A y viceversa:

Arquitecturas de replicación

Esta aproximación sin embargo tiene un problema importante que seguramente aquellos ya duchos en replicación han detectado inmediatamente: la gestión de conflictos. Si por ejemplo de forma “simultánea” es decir, dentro del periodo de varios segundos que puede necesitar la réplica en sincronizar, los usuarios A y B insertaran un nuevo cliente con el mismo DNI (que presuponemos único) tendríamos un conflicto de unicidad al proceder a realizar la inserción tanto en A como en B. Para estos escenarios tenemos varias alternativas como tener en cuenta la posibilidad de conflictos en los procedimientos almacenados personalizados. Una política básica para podría ser el almacenar en una tabla de errores los conflictos y lanzar una alerta para que un administrador lo solucione manualmente. Una política un poco más compleja sería dar prioridad a uno de los dos sistemas. Si el sistema A fuese prioritario deberíamos al replicar de A a B una inserción, realizar bien un UPDATE del registro o bien un DELETE previamente a la inserción. Si estamos replicando de B a A simplemente descartaríamos la inserción en caso de encontrarnos ya con datos “en el sistema A que generaran colisión.

Otra alternativa posible sería utilizar un modelo de replicación que ya incorpore resolución de conflictos de forma nativa. Por ejemplo podríamos utilizar una replicación de mezcla 1 a 1. Para solucionar el problema del “interfaz” recurriríamos a crear un “meta modelo” orientado a la replicación el cual se sincroniza normalmente de forma “local” con after-triggers . La arquitectura quedaría algo así:

Arquitecturas de replicación

De esta forma la resolución de conflictos se llevaría a cabo por el agente de réplica de mezcla y el resultado de la sincronización dependería de la configuración de éste. Podemos determinar que la resolución de cambios se aplique a nivel de columna con lo que podrían llegar a realizarse dos updates convurrentes sobre un mismo cliente. Un cambio en A (cambio de dirección) y otro en B (cambio de teléfono) generaría un resultado final con ambos cambios aplicados en los dos sistemas. Aunque la replicación de mezcla habitualmente es más lenta que la replicación transaccional si conocemos bien nuestro sistema y los dos servidores están en red local podemos “forzarla” a trabajar en periodos de baja frecuencia con lo que podemos conseguir latencias de pocos segundos.

En el caso que el uso de triggers tradicionales (síncronos) no sea aceptable para la sincronización con el modelo “local” sería posible también simular una especie de triggers “asíncronos”. Obviamente cuanto más compliquemos el sistema más tiempo deberemos dedicar a su mantenimiento y a asegurar su buen funcionamiento a lo largo del tiempo (cambios de esquema, impacto en procesos masivos, etc.) pero puede que los beneficios de la integración sean mayores que los costes.

La replicación de SQL Server es una tecnología que nos aporta muchas posibilidades para el diseño de soluciones de sincronización. En los casos más sencillos únicamente con el asistente gráfico y unos pocos minutos podremos tener nuestra replicación en marcha. En otros casos la solución será más compleja para cubrir necesidades especiales. En esos casos podemos tener que desarrollar componentes adicionales como procedimientos almacenados personalizados, triggers de integración, resolutores de conflictos personalizados o bien integrar la réplica con colas de Service Broker/MSMQ. Estos casos complejos deberemos afrontarlos como cualquier otro desarrollo de una solución software con su fase de análisis, diseño, implementación, pruebas, despliegue y su posterior soporte. Durante esta fase de diseño haremos bien en evaluar las distintas modalidades de replicación nativa de SQL Server disponibles como un componente clave para la sincronización de datos entre bases de datos.

 

0 Shares:
5 comments
  1. Sé que han pasado alrededor de 6 años de publicado este artículo, sin embargo, quería saber si existe algún escenario de “alta rendimiento” que maneje SQL Server, a parte de la opción de replicación de sus bases de datos. Dado que según lo investigado hasta el momento, la tecnología de SQL Server no tienen en si un tema específico de alto rendimiento con cluster de servidores SQL.

    1. Hola Christian, entiendo que con escenario de ‘alta rendimiento’ te refieres es a algún tipo de cluster activo-activo estilo RAC de Oracle. Si es eso lo que buscas, no existe 🙂 Lo más parecido son los grupos de disponibilidad (AG Availability Groups) que permiten 1 nodo escritor y N de lectura. Si tienes cualquies otra duda no dudes en escribirnos. Gracias!

  2. en una base Azure SQL. Las bases de datos a replicar están en SQL Express, sé que no puedo usarlas como replicador o distribuidor, pero sí como suscriptores. Es posible utilizar Azure SQL en este caso? Gracias!

    1. Actualmente no es posible utilizar Azure SQL Database como publicador ni como distribuidor. Lo mismo ocurre con Azure SQL Database Managed Instances aunque esto podría llegar a cambiar en un futuro. A día de hoy la única opción para tener ese rol de publicador/distribuidor en Azure pasa por configurar una máquina virtual con SQL Server.

  3. Buenos días estimado en la actualidad deseaba preguntarle si las versiones de sql 2019 ya podra ser bidireccional las replicas ?

    —————————-
    No hay cambios significativos en la replicación en SQL Server 2019. Por tanto las modalidades soportadas, su unidireccionalidad/bidireccionalidad no cambian respecto a versiones anteriores.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

You May Also Like