Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

SymmetricDs, Herramienta de Replicación de Código Abierto



  1. Qué es SymmetricDS
  2. Esquemas de Notificación
  3. Sincronización bidireccional de tablas
  4. Filtrado y re-enrutado de datos
  5. Configuración básica
  6. Arquitectura
  7. Consideraciones finales
  8. Bibliografía

Qué es SymmetricDS

SymmetricDS es un software de replicación de datos asíncrona que permite subscriptores múltiples y sincronización bidireccional. Utiliza tecnologías web y de bases de datos para replicar tablas entre bases de datos relacionales, casi en tiempo real. El software fue diseñado para escalar a un gran número de bases de datos, trabajar con conexiones de bajo ancho de banda, y resistir a periodos de inoperatividad de la red.

El software se instala o bien de modo autónomo, como una aplicación web dentro de servidor de aplicaciones Java, o puede ser incorporado a otra aplicación Java.

Una única instalación de SymmetricDS se denomina un Nodo. Un Nodo es inicializado mediante un fichero properties, y es configurado insertando datos de configuración en una serie de tablas de base de datos. A continuación, el Nodo crea triggers de base de datos en las tablas de aplicación especificadas, de modo que los eventos de base de datos son capturados para ser entregados a otros Nodos SymmetricDS.

SymmetricDs está escrito en Java 5 y require Java SE Runtime Environment (JRE) o Java SE Development Kit (JDK) version 5.0 o superior. Soporta la sincronización entre diferentes plataformas de base de datos, mediante el concepto de dialectos de base de datos. Un dialecto de base de datos es una capa de abstracción con la cual interactúa SymmetricDS para aislar la lógica de sincronización de los detalles de implementación específicos de cada base de datos.

Esquemas de Notificación

Tras registrar un cambio que se ha producido en la base de datos, los nodos interesados en el cambio son notificados. La notificación de cambios se configura para realizar un push o un pull. Cuando varios nodos dirigen sus cambios a un nodo central, es eficiente realizar un push de los cambios, en vez de esperar a que el nodo central realice un pull de cada nodo origen. Cuando la configuración de red protege a un nodo con un firewall, una configuración pull permite que el nodo reciba cambios de datos que de otro modo podrían ser bloqueados utilizando push. La frecuencia de la notificación de cambios es de un minuto en la configuración por defecto

Sincronización bidireccional de tablas

Algunos datos pueden requerir la sincronización en ambos sentidos. SymmetricDS permite la sincronización bidireccional, y evita incurrir en bucles.

Filtrado y re-enrutado de datos

Los datos pueden ser filtrados como son registrados, extraídos y cargados.

  • El enrutamiento y filtrado de los datos se especifica mediante expresiones SQL en la configuración de los trigger. Las expresiones SQL son configuradas en el node_select (para el enrutamiento en tiempo real) y en el initial_load_select (para la carga inicial de datos). Las expresiones SQL se utilizan para crear el SQL trigger que SymmetricDS instala para capturar los cambios de los datos. Usando esta técnica los datos pueden enviarse a un nodo específico o a un grupo de nodos.

  • Los datos pueden ser filtrados, ya sea cuando se cargan en la base de datos de destino o cuando se extrae una base de datos fuente. El filtro puede impedir que los datos lleguen a la base de datos en conjunto, reemplazando de manera efectiva la carga de datos por defecto.

  • Se pueden excluir columnas de la sincronización para que nunca se registren cuando la tabla se cambia. Como los cambios de datos se cargan en la base de datos de destino, una clase que implementa IColumnFilter puede remover una columna de la sincronización.

Configuración básica

Para mantener corriendo una instancia de SymmetricDS, es necesario tener una identidad y conocer cómo conectarse a la base de datos que se manejará. Una forma básica para especificar esto es en el fichero symmetric.propertie. Cuando el SymmetricDS se inicia lee esta configuración y el estado de la base de datos. Si las tablas de configuración no existen, son creadas automáticamente. Una configuración básica describe lo siguiente.

Node Group – cada Node pertenece a un grupo. Una categoría de Nodos que sincroniza datos con uno o más Grupos de Nodos. Un uso común de Grupos de Nodos es para describir un nivel en la jerarquía de la sincronización de datos.

Node Group Link – dos Nodes Groups son enlazados a través de la sincronización. Especifica el esquema de notificación (Push- P , Pull – W Wait for Pull o personalizado por el usuario) a utilizar para enviar datos cambiados en un grupo de nodo a otro grupo de nodos. Para establecer la sincronización entre Nodos, dos Grupos de Nodos deben ser enlazados entre ellos. La dirección de la sincronización es determinada por la especificación de un Grupo de Nodos fuente y uno destino. Si la sincronización ocurre en ambas direcciones, entonces dos enlaces son creados en direcciones opuestas. El Grupo de Nodos destino recibe los datos cambiados por un método pull o push. Un método push causa que el Grupo de Nodos fuente se conecte al destino, mientras que un pull causa una espera hasta que el destino se conecte.

Channel – los datos son categorizados para sincronizar independientemente. Los cambios en la base de datos son capturados en el orden en que ocurren y se conserva durante la sincronización con otros nodos. Algunos datos pueden necesitar una prioridad para la sincronización independientemente del orden normal de los acontecimientos. Los canales proporcionan un orden de procesamiento de más alto nivel para los datos, una limitación en la cantidad de datos, y el aislamiento de los errores. Al clasificar los datos en los canales, el usuario tiene más control y visibilidad sobre el flujo de los mismos.

Trigger – especifica qué cambios en la base de datos serán capturados. El corazón del SymmetricDS son los trigger que definen que datos se capturan. Los Nodos en el Grupo de Nodos fuente capturarán los cambios de una tabla y los enviarán al Grupo de Nodos destino. Los cambios pueden incluir inserción, actualización o eliminación en la tabla, y estos datos pueden ser filtrados por una expresión condicional. La condición puede ser especificadas para capturar los cambios de la fila en la base de datos. Si la condición se cumple, los cambios son capturados y enviados al destino. Si la condición no se cumple, se permite el cambio de los datos, pero estos no son capturados y enviados al destino. Las condiciones corren dentro del contexto del evento de trigger de la base de datos, y usa el lenguaje específico de la plataforma de la base de datos. Una condición puede ser especificada para una inserción, actualización y eliminación, y esta corre para cada fila del evento.

Durante la puesta en marcha, los trigger son verificados contra la base de datos, y son instalados en las tablas que requieren que los cambios sean capturados. El PullJob y PushJob comienzan a correr para sincronizar los cambios con otros Nodos.

5.1 Propiedades básicas

Cada Nodo requiere propiedades que conectarán este con la base de datos y con el Nodo padre. Para dar a un Nodo su identidad, se usan las siguientes propiedades:

group.id

El Grupo al cual pertenece el Nodo. La sincronización se realiza entre Grupos de Nodos.

external.id

El ID externo para del nodo, tiene un significado para el usuario y ofrece una integración en el sistema en que esté desplegado. El identificador externo se puede utilizar en expresiones condicionales. Transparente para al usuario, cada nodo tiene un número de secuencia única para el seguimiento de eventos de sincronización. Es posible asignar el mismo identificador externo a varios nodos, si se desea.

my.url

El URL donde el Nodo puede ser contactado para sincronizar.

Cuando un Nodo se inicia por primera vez, este no tiene información sobre la sincronización. Este contacta con el servidor de registro para unirse a la red y recibir su configuración. La configuración de los Nodos es almacenada en el servidor de registro, y el URL debe ser especificado en la propiedad:

registration.url

El URL donde el Nodo puede conectarse para registrarse y recibir su configuración.

Para una implementación de un servidor de aplicaciones, es común que los grupos de conexión de base de datos que se recogen en el directorio de nombre Java (JNDI). En este caso, establezca la propiedad siguiente

db.jndi.name

El nombre de la agrupación de conexiones de base de datos que se registra en el árbol de directorios JNDI del servidor de aplicaciones. Se recomienda que esta NO es DataSource transaccional, porque SymmetricDS se encargará de sus propias transacciones.

Para un despliegue donde la conexión a la base de datos se a través de JDBC, se utiliza la siguiente propiedad:

db.driver

Nombre de la clase del driver para JDBC

db.url

El URL de la JDBC usado para conectar la base de datos

db.user

El nombre del usuario para conectarse a la base de datos.

db.password

La clave del usuario de la base de datos. Esta puede estar encriptada.

5.2 Conceptos

Muchos de los conceptos de sincronización de datos pueden ser comprendidos examinando el modelo de datos. El modelo de datos de configuración es un conjunto de tablas actualizadas por el usuario como sea necesario para configurar el sistema. Por el contrario, el conjunto de tablas para el modelo de datos de tiempo de ejecución cambia constantemente conforme el sistema captura cambios en los datos y registra la actividad para entregarlos. 

Todos los nombres de tabla tienen un prefijo configurable, para que varias instancias de SymmetricDS puedan coexistir en la misma base de datos. El prefijo por defecto es sym_.

5.3 Modelo de datos de configuración

La configuración es introducida por el usuario en el modelo de datos para controlar el comportamiento de qué datos son sincronizados con qué nodos. Para facilitar la administración de varias bases de datos, los nodos son incluidos en grupos, y los grupos se enlazan entre sí para la sincronización. Un trigger captura datos para una tabla, que puede incluir condiciones y criterios para subconjuntos. Los triggers se agrupan en canales para la priorización y control del flujo de datos.

Las tablas que intervienen en este modelo son:

  • node

  • node_security

  • node_identity

  • node_group

  • node_group_link

  • channels_table

  • node_channel_ctl

  • =

Arquitectura

La aplicación SymmetricDS permite que los cambios de entrada y de salidas sean sincronizadas con otras bases de datos. El nodo que inicia la conexión es el cliente y el nodo que la recibe es el servidor. Dado que la sincronización está configurada para extraer o enviar en cualquier dirección, el mismo nodo puede actuar a la vez como cliente o como servidor en diferentes circunstancias.

La aplicación consiste una serie de tareas, administradores, servlets, y servicios que se ofrecen juntos usando la inyección de dependencia de Spring Framework.

Figura 6.1. Esquema de funcionamiento de la aplicación

Como cliente, el nodo ejecuta el trabajo de envío y extracción en el hilo de un contador que se sincroniza con el nodo servidor. El envío usa los servicios de procesamiento por lotes, extracción, y envía datos a otro nodo. La respuesta a un envío es una lista de recibo de procesamiento por lotes que indica que el dato fue cargado. El trabajo de extracción usa el servicio para cargar datos que se envía desde otro nodo. Después que se cargan los datos, se hace una segunda conexión para enviar una lista de confirmación de recepción de procesamiento en lotes.

Como servidor, el nodo espera las conexiones entrantes que extraen, envían o confirman cambios en los datos. El servlet de envío usa los servicios para cargar los datos que se envían desde el nodo cliente. Después de cargar los datos, responde con una lista de confirmación de recibo de procesamiento en lotes. El servlet de extracción usa los servicios de procesamiento en lotes, extracción y envío de datos hacia el nodo cliente. EL servlet de confirmación de recibo usa los servicios para actualizar el estado de los datos que se cargaron en el nodo cliente.

El administrador de Transporte maneja los flujos de datos que salen y entran entre los nodos. El transporte por defecto está basado en una simple implementación sobre el protocolo HTTP. También se suministra un transportador interno. Es posible además adicionar otras implementaciones, como la de un administrador de transporte basado en socket.

La comunicación del nodo usando HTTP se representa en la siguiente figura.

Fig. 6.2 Comunicación del nodo

La API SymmetricEngine puede ser usada para iniciar, de forma directa, solamente los servicios del cliente. La API SymmetricWebServer puede ser usada para iniciar, de forma directa, ambos servicios, cliente y servidor dentro de un contenedor web Jetty.

Consideraciones finales

Las bases de datos distribuidas son cada vez más usadas por las empresas y suponen una ventaja competitiva frente a los sistemas centralizados, siempre y cuando la empresa en cuestión tenga necesidad de usar una base de datos de este tipo. Lo más habitual es disponer de varias sedes y tener que manejar información común, para lo cual las bases de datos distribuidas son especialmente útiles.

Es una tecnología que ya lleva años en rodaje por lo que tiene la madurez suficiente como para ser usada con garantías, no obstante, debido a la gran dependencia que estas bases de datos tienen de las telecomunicaciones, en España nos encontramos muchos problemas para conseguir el rendimiento oportuno de las mismas.

SymmetricDS constituye una potente herramienta para la replicación de datos, ya sean homogéneos o no, independiente del gestor de base de datos que se utilice, siempre y cuando soporte la tecnología de trigger y driver JDBC. Es una herramienta en constante evolución con una amplia comunidad, fácil de aprender y con más de una posibilidad para su despliegue, lo que permite usar la forma más adecuada según las características del hardware que se posea. Su configuración es manejada centralmente.

Bibliografía

M. Tamer Ozsus, Patric Valduriez Principles of distributed database systems, Second Edition, 1999

Ceri, S., Pernici, B., Wiederhold, G. Distributed Database Design Methodologies. Proceedings of the IEEE, Vol. 75, No. 5, May 1987.

Meghini, C., Thanos, C. The Complexity of Operation on a Fragmented Relation. ACM Transaction on Database Systems, Vol. 16, No. 1, March 1991.

Eric Long, Chris HensonSymmetricDS User Guide 1.0.pdf, 2007 – 2008

Sitio Web: www.symmetricds.org

Sitio Web: http://symmetricds.codehaus.org

Sitio Web: www.cs.valberta.ca/~database/distrib.html

 

 

 

Autor:

Lic. Vivian Romero Buchillón

Ing. Diosmani Meriño Hechavarría

 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter