Capítulo 1. Introducción

1.1. Introducción

1.1.1. 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 fué 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 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 impementación específicos de cada base de datos.

1.1.2. 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 poll. 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 configuracion 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.

1.1.3. Sincronización bidireccional de tablas

Algunos datos deben ser sincronizados en una dirección. Por ejemplo, una tienda de venta al por menor envía sus ventas a una oficina central, y la oficina central envía los artículos que tiene en stock a la tienda. Algunos datos pueden requerir la sincronización en ambos sentidos. Por ejemplo, la tienda envía a la oficina central un documento de inventario, y la oficina central actualiza el status del documento, que es enviado de regreso a la tienda. SymmetricDS permite la sincronización bidireccional, y evita incurrir en bucles de actualización porque sólo registra cambios de datos fuera de la sincronización.

1.1.4. Canales de Datos

La sincronización de datos se define al nivel de tabla (o de subconjunto de tabla). Cada tabla gestionada puede ser asignada a un canal que ayuda a controlar el flujo de datos. Un canal es una categoría de datos que puede ser habilitada, priorizada y sincronizada independientemente del resto de canale. Por ejemplo, en un entorno de venta al por menor, los usuarios pueden estar esperando a que se actualicen los documentos de inventario mientras un envento de venta promocional actualiza un gran número de artículos. Si se procesaran en orden, las actualizaciones de artículos retrasarían las actualizaciones de inventario aún cuando los datos no tienen relación. Asignando los cambios que se realizan a la tabla de artículos al canal "artículo", y los cambios que se realizan a la tabla de inventario al canal "inventario", los cambios son procesados independientemente de modo que el inventario pueda ser actualizado.

1.1.5. Transaction Awareness

Muchas bases de datos proporcionan un identificador de transacción asociado a las filas que son actualizadas (commited) conjuntamente. SymmetricDS almacena el ID de transacción junto con los datos que han cambiado, de modo que puede volver a ejecutar la transacción exactamente del mismo modo que ocurrió. Esto significa que la base de datos de destino mantiene la misma integridad que la fuente. El soportee al ID de transacción se docuemnte en un apéndice de esta guía.

1.1.6. Data Filtering and Rerouting

Data can be filtered as it is recorded, extracted, and loaded.

  • Data routing and filtering is specified using SQL expressions in the trigger configuration. The SQL expressions are configured in the node_select (for real time routing) and initial_load_select (for initial data loads) columns of the Section 3.1.8, “Trigger Table”. The SQL expressions are used to create the SQL triggers that SymmetricDS installs to capture data changes. Using this technique data can be routed to a specific node or group of nodes.

  • As data changes are loaded in the target database, a class implementing IDataLoaderFilter can change the data in a column or route it somewhere else. One possible use might be to route credit card data to a secure database and blank it out as it loads into a centralized sales database. The filter can also prevent data from reaching the database altogether, effectively replacing the default data loading.

  • Columns can be excluded from synchronization so they are never recorded when the table is changed. As data changes are loaded into the target database, a class implementing IColumnFilter can altogether remove a column from the synchronization. For example, an employee table may be synchronized to a retail store database, but the employee's password is only synchronized on the initial insert.

  • As data changes are extracted from the source database, a class implementing the IExtractorListener interface is called to filter data or route it somewhere else. By default, SymmetricDS provides a handler that transforms and streams data as CSV. Optionally, an alternate implementation may be provided to take some other action on the extracted data.

 

1.1.7. HTTP Transport

By default, SymmetricDS uses web-based HTTP in a style called Representation State Transfer (REST) that is lightweight and easy to manage. A series of filters are also provided to enforce authentication and to restrict the number of simultaneous synchronization streams. The ITransportManager interface allows other transports to be implemented. (The unit tests for SymmetricDS take advantage of this by using an InternalTransportManager that makes it easy to run automated tests locally.)

1.1.8. Remote Management

Administration functions are exposed through Java Management Extensions (JMX) that can be accessed from the Java JConsole or through an application server. Functions include opening registration, reloading data, purging old data, and viewing batches. A number of configuration and runtime properties are available to be viewed as well.

SymmetricDS also provides functionality to send a SQL events through the same synchronization mechanism that is used to send data. The data payload can be any SQL statement. The event is processed and acknowledged just like any other event type.

1.2. Requirements

SymmetricDS is written in Java 5 and requires a Java SE Runtime Environment (JRE) or Java SE Development Kit (JDK) version 5.0 or above.

Any database with trigger technology and a JDBC driver has the potential to run SymmetricDS. The database is abstracted through a Database Dialect in order to support specific features of each database. The following Database Dialects have been included with this release:

  • MySQL version 5.0.2 and above

  • Oracle version 8.1.7 and above

  • PostgreSQL version 8.2.5 and above

  • Sql Server 2005

  • HSQLDB 1.8

  • H2 1.1

  • Apache Derby 10.3.2.1 and above

  • IBM DB2 9.5

  • Firebird 2.0 and above

See the appendix B for compatibility notes and other details for your specific database.

1.3. Background

While implementing a commercial Point of Sale (POS) system for a large retailer, the development team concluded that the software available for trickling back transactions to the general office did not meet the project needs. The list of problems in the requirements made finding the ideal solution difficult:

  • Sending and receiving data with 2000 stores during peak holiday loads.

  • Supporting one database platform at the store and another at general office.

  • Synchronizing some data in one direction, and other data in both directions.

  • Filtering out sensitive data and re-routing it to a protected database.

  • Preparing the store database with an initial load of data from general office.

The team created a custom solution that met the requirements and made the project successful. From this initial challenge came the knowledge and experience that SymmetricDS benefits from today.