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:

Base de datos Oracle Base de datos no Oracle Otras fuentes
GoldenGate Classic for Oracle GoldenGate for Postgresql
GoldenGate for MySQL
GoldenGate for DB2
GoldenGate for SQL Server
GoldenGate Classic for Big Data

Componentes principales

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

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

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:

ETAPA TIPO DE ELEMENTO UBICACIÓN FUNCIÓN
CARGA INICIAL EXTRACT GG Origen Extraer del origen el conjunto de datos de inicio a replicar
CARGA INICIA REPLICAT GG Destino Replica los cambios en el destino correspondientes a los datos obtenidos
CDC EXTRACT GG Origen Extraer, de forma continua, los cambios realizados en el origen y crear el trail local
CDC DATA PUMP GG Origen Procesar el trail local y generar el trail remoto para enviar al destino
CDC REPLICAT GG Destino Procesar el trail remoto y aplicar los cambios en la fuente destino

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.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete

Estamos comprometidos.

Tecnología, personas e impacto positivo.