Al hilo del post que publiqué la semana pasada en el Blog de Estrategia y Dirección, describimos a continuación las topologías más frecuentes que podemos encontrarnos en la empresa, a las que debe dar soporte un sistema de respaldo de datos en tiempo real.
- Unidireccional: 2 bases de datos, la principal
(producción) activa, contra la que se ejecutan las aplicaciones. Una base de datos secundaria pasiva (inactiva) hacia la que se replican los cambios en tiempo real. Además de como sistema de respaldo (backup), la base de datos secundaria puede utilizarse como servidor estadístico del que lean los datos las aplicaciones de Business Intelligence (BI). También puede utilizarse esta topología durante procesos de migración o actualización de aplicaciones, mientras coexisten las 2 aplicaciones o versiones distintas; la aplicación o versión a sustituir se ejecuta contra la base de datos principal, la nueva sobre la secundaria, en el momento en que se decide abandonar definitivamente la principal, la secundaria está actualizada.
- Bidireccional: los procesos de
sincronización se ejecutan en las 2 direcciones, simultáneamente (active – active), o uno en cada momento (live standby).
- El modo live standby es el típico de los sistemas de respaldo, donde se replican los cambios entre el servidor principal (activo) y el secundario (pasivo). Cuando se produce una incidencia en el principal, los usuarios pasan a trabajar contra el secundario y en ese momento se cambia el sentido de la replicación para que el sistema principal se mantenga actualizado para cuando podamos volver a trabajar sobre él.
- El modo active – active es el más potente pues permite que parte de los usuarios o centros de la empresa trabajen contra una base de datos, mientras que otros trabajan sobre la otra, de manera que se balancea o distribuye la carga. El inconveniente es que requiere de una adecuada parametrización de las aplicaciones que escriben en las bases de datos, la programación de reglas para una adecuada gestión de conflictos, y la detección de posibles bucles de actualización (principal actualiza secundario, secundario trata de actualizar el mismo cambio en principal).
- Peer-to-Peer: es una variante del modelo bidireccional,
en el que más de 2 bases de datos se comunican entre sí por parejas, cada una con otras dos. Técnicamente es el más complejo en cuanto a gestión de conflictos, pues el mismo registro en una de las bases de datos podría llegar a ser modificado en este modelo hasta por tres bases de datos distintas (la propia y las otras dos con las que está conectada).
- Broadcast: es una variante del modelo
unidireccional en el que los cambios en la base de datos principal se replican en más de una base de datos de destino inactivas. Uno de los usos más frecuentes es para disponer separadamente de una base de datos de respaldo (backup) y otra como servidor estadístico para la creación de informes y cuadros de mando.
- Integración/Consolidación: variante del modelo
unidireccional en el que hay más de una base de datos origen y una única base de datos de destino. Es el modelo apropiado cuando deseamos construir un almacén de datos corporativo (Data Warehouse) que integre/consolide los distintos orígenes de datos de la organización. La base de datos del Data Warehouse es la que actúa como servidor estadístico. De nuevo en este modelo se hace imprescindible una adecuada gestión de conflictos, pues podrían ser varias las bases de datos origen que intentaran actualizar simultáneamente el mismo registro en la base de datos destino. Normalmente se definen reglas de negocio en forma de filtros en origen que limiten los cambios a replicar para cada base de datos y así evitar la posible colisión.
- En Cascada: variante del modelo unidireccional en
el que la base de datos secundaria (B) replica a su vez los cambios de la principal (A) en otras bases de datos (C,D,E…), actuando como intermediaria. Es apropiado cuando:
- No disponemos de conexión directa entre la base de datos principal (A) y las finales (C,D,E…)
- Deseamos limitar el tráfico de red saliente desde la principal.
- No deseamos cargar la base de datos principal o finales con operaciones de transformación o filtrado sobre los registros que suelen ser costosas en términos de CPU y RAM.
- Hay una distancia física considerable entre la base de datos principal y las finales que limita técnicamente la velocidad de transmisión de la línea de comunicación. Usamos la base de datos intermediaria (B) ubicada geográficamente en un lugar intermedio entre la principal y las finales.
Sergio Álvarez Clau
Consultor de Negocio -DATADEC-