Arquitecturas de replicación

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:

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:

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í:

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.