¿Qué es Oracle GoldenGate?

Este es el primer post de la serie dedicada a CDC (Change Data Capture) utilizando Oracle GoldenGate. Empezaremos por un post de contenido teórico y continuaremos con una serie de posts más prácticos orientados a satisfacer determinados casos de uso.

Introducción: qué es Oracle GoldenGate

Oracle GoldenGate es una solución de CDC para la replicación de datos entre diferentes orígenes y destinos en tiempo real.

Esto permite, por ejemplo, replicar datos entre los sistemas operacionales y sistemas analíticos o informacionales en tiempo real, manteniendo siempre la integridad de los datos.

Además, mediante GoldenGate podemos replicar datos entre diferentes tipos de fuentes, incluyendo desde bases de datos a servicios Cloud (AWS, GCP, Azure) o un bus de eventos como Kafka.

Al estar basado en la lectura de logs transaccionales, no afecta al rendimiento del motor de base de datos.

Un “GoldenGate” para cada fuente

Cuando hablamos de Oracle GoldenGate seguramente estemos pensando en un único componente que se conecta a todos los destinos y orígenes. Realmente esto no es así y, en la práctica, usamos diferentes “tipos” de Oracle GoldenGate según las fuentes con las que estemos trabajando.

Lo podemos ver rápidamente si accedemos a la página de descargas. Si tenemos en cuenta la fuente, los más importantes son:

Componentes principales

Vamos a explicar muy brevemente cuáles son los componentes principales de Oracle GoldenGate:

• Extract: encargado de capturar los cambios que se producen en la base de datos origen a partir de los logs transaccionales.
• Ficheros “trail”: ficheros binarios, generados a partir de los cambios detectados, que se mandan a los diferentes destinos.
• Data pump: conocido también como extract secundario. Es el responsable de enviar los ficheros locales de “trail”, que contienen los cambios en el sistema origen, al sistema destino para que se pueda efectuar la replicación. Es un componente opcional pero muy recomendable ya que permite desacoplar el extract del destino.
• Replicat: se ejecuta en el sistema destino y es el encargado de aplicar, en la fuente de destino, los cambios recibidos en el fichero “trail” para efectuar la replicación.

Además, existen dos componentes que son los encargados de orquestar todo el proceso:

• Server Collector: se ejecuta en el sistema destino y es el que realmente acepta los datos procedentes del origen. En el caso de que los datos se manden cifrados, es el encargado de realizar el descifrado.
• Manager: se ejecuta tanto en el origen como en el destino y es el encargado de arrancar, parar, monitorizar o lanzar errores de los diferentes elementos.

La siguiente imagen describe de forma gráfica todos los elementos involucrados en un proceso típico de replicación:

Proceso de replicación

Cuando hablamos de Change Data Capture (CDC), hablamos de un proceso de replicación continua de datos.

En la mayoría de procesos de replicación continua, se suelen diferenciar dos pasos o etapas:

1. Carga inicial: replicará todos los datos existentes en el origen en la base de datos destino. Este proceso se ejecuta solo una vez, al inicio, consiguiendo que todo el conjunto de datos del origen que queremos replicar esté en la base de datos destino.
   Es decir, establece un punto de partida en el que ambas fuentes, origen y destino, están sincronizadas.
   Hay que tener en cuenta que, en la carga inicial, los datos no se obtienen de los ficheros de logs sino que se accede a consultar el modelo directamente de la base de datos, obteniendo el conjunto total de datos existente. Esta etapa sí afecta al rendimiento del motor.
2. CDC (Change Data Capture): si nos quedamos únicamente en la etapa anterior, tendremos únicamente una migración de datos o un backup en un momento dado.
   Si queremos mantener las dos bases de datos sincronizadas a lo largo del tiempo, tenemos que implementar esta segunda etapa. Aquí es donde verdaderamente implementamos un proceso de CDC, capaz de detectar cualquier cambio en el origen y replicarlo en el destino.

Componentes implicados en cada etapa

En la siguiente imagen podemos ver los diferentes componentes implicados en ambas etapas:

De forma resumida, vamos a ver cada componente, su responsabilidad y dónde se ubica:

Hay que tener en cuenta que, aunque son dos etapas diferentes, se implementan a la vez. Esto se debe a que, una vez concluida la carga inicial, los componentes asociados a la etapa propia de CDC deben estar “up & running” para no perder ningún cambio en las tablas seleccionadas y que no haya que repetir un proceso de carga inicial para dejar ambas fuentes (origen y destino) sincronizadas de nuevo.

Oracle GoldenGate Classic y Microservices

Si vamos a la página de descargas de GoldenGate veremos que existe una versión “Microservices”, y podemos preguntarnos a qué se refiere. Por ejemplo, ya en la versión 19.1.0.0.4, podemos encontrar los dos tipos de descargas:

La diferencia está en la arquitectura sobre la que se ha desarrollado el propio producto GoldenGate, encontrando, a nivel interno, una versión más monolítica (versión “Classic”) y una versión modularizada (versión “Microservices”).

A nivel de uso, en la interacción con GoldenGate también encontraremos diferencias. En la versión “Classic” usaremos un cli, GGSCI y scripts, mientras que en la versión Microservices usaremos la consola web o el API Rest.

En la mayor parte de los posts siguientes nos vamos a basar en la versión “Classic”, ya que así conseguimos una visión completa de los componentes y su funcionamiento. Sin embargo, en los post finales de la serie hablaremos también de la versión “Microservices”

Oracle GoldenGate Cloud Service

Dentro de los servicios que podemos encontrar en Oracle Cloud disponemos de un servicio totalmente gestionado de Oracle GoldenGate. Este servicio se basa en Oracle GoldenGate Microservices y pone a nuestra disposición la consola web en la que podremos gestionar los diferentes elementos.

De igual manera que con la versión Microservices, la mayor parte de los post van a ir orientados a un entorno no gestionado y se utilizará principalmente la versión “Classic”, en los post finales de la serie hablaremos más en detalle del servicio Cloud.

Manos a la obra

Como hemos comentado al inicio, el objetivo de este post es introducir Oracle GoldenGate. En los próximos post de la serie vamos a ver ejemplos prácticos basados en casos de uso de Negocio:

1. Replicación unidireccional, heterogénea, de Oracle a Postgresql, y separando los datos de una única tabla de clientes, en origen, en dos tablas en destino, para diferenciar los clientes particulares y empresas y mostrando cómo se podría lograr una replicación de datos hacia una instancia en Cloud.
2. Publicación de cambios en el bus de eventos, viendo cómo es posible publicar solo determinados eventos asociados a tablas. Por ejemplo, la inserción de filas correspondientes a nuevos clientes, ignorando las acciones de actualización o eliminación.
3. Replicación bidireccional, heterogénea, evolucionando el punto 1 y permitiendo que los datos se consoliden desde dos tablas diferentes, particulares y empresas, en el modelo de la actual base de datos Oracle, consistente en una única tabla.
4. Replicación bidireccional, heterogénea, de Oracle a Postgresql, utilizando Oracle GoldenGate Microservices, implementando el mismo caso de uso que en el punto 3.
5. Bonus track: replicación bidireccional completa con GoldenGate Microservices: realizamos el mismo caso funcional, replicando de forma bidireccional entre Oracle y Postgresql pero utilizando solo la versión Microservices.