Este es el segundo post de la serie dedicada a Oracle GoldenGate. En este post vamos a tratar un caso de uso en el que nos encontramos con una compañía que, desde hace años, ofrece un servicio mayoritariamente a clientes particulares. Los clientes de tipo empresarial, hasta ahora, han sido residuales. Desde Negocio se quiere separar totalmente ambos tipos de clientes para permitir una evolución acorde a las peculiaridades de cada escenario (particular / empresa) y poder impulsar los empresariales.

A nivel técnico, se dispone de un único servicio de clientes apoyado en una base de datos Oracle. El modelo de datos consiste en una única tabla CUSTOMERS, con todos los datos mezclados y columnas específicas para un tipo, pero sin sentido para el otro (ej: “nombre” y “razonsocial”, o “nif” y “cif”).

Dada esta problemática, se decide optar por las siguientes acciones iniciales:

La siguiente imagen describe los dos escenarios, el actual y el objetivo, incluyendo la herramienta de CDC:

Diseñando el proceso de replicación

Uno de los pasos fundamentales es el diseño del proceso de replicación, en el que vamos a analizar qué datos extraer y cómo y dónde los vamos a replicar.

¿Qué “GoldenGates” necesitaremos?

Como vimos en el post inicial de la serie, Oracle GoldenGate no es una única herramienta sino que, dependiendo de las fuentes con las que vayamos a trabajar, necesitaremos usar uno o varios componentes. En este caso, trabajaremos con Oracle y con Postgresql, por lo que necesitaremos un GoldenGate para interactuar con cada una. La arquitectura queda de la siguiente manera:

Selección de datos

En este caso, partimos de una tabla en la que existen datos de dos tipos de clientes diferentes: particulares y empresas.

La columna TIPO es la que se utiliza para saber si un cliente es particular (con valor 1) o empresa (con valor 2). Teniendo en cuenta esto, en el proceso de replicación tenemos que establecer un mapeo basado en la columna TIPO, y la consecuente relación de columnas y destinos:

Tratamiento de secuencias

Los identificadores de las tablas son un punto clave en cualquier proceso de replicación. En muchas ocasiones, se trabaja con secuencias o campos autoincrementales. En este caso:

Como estamos implementando una replicación unidireccional y, de momento, no se van a insertar datos directamente en destino, disponemos de una única fuente de verdad, que es Oracle. En destino (Postgresql), los datos se insertarán con la clave primaria de Oracle, generada por una secuencia.

En Postgresql nos vamos a encontrar con que las claves primarias de las tablas pueden no ser consecutivas, pero realmente no es un problema, ya que garantizan la unicidad de las claves.

Definiendo las etapas del proceso

Como hemos visto en el primer post, tenemos dos etapas en el proceso de replicación:

Teniendo en cuenta estas dos etapas, vamos a definir los elementos que intervendrán en cada una de ellas para pasar posteriormente a su implementación:

ETAPA TIPO DE ELEMENTO UBICACIÓN FUNCIÓN NOMBRE
CARGA INICIAL EXTRACT GG Classic Extraer de Oracle el conjunto de datos de inicio a replicar einiload
CARGA INICIAL REPLICAT GG Postgresql Replica los cambios en Postgresql correspondientes a los datos extraídos riniload
CDC EXTRACT GG Classic Extraer, de forma continua, los cambios realizados en Oracle y crear el trail local riniload
CDC DATA PUMP GG Classic Procesar el trail local y generar el trail remoto para enviar al destino pcdcora
CDC REPLICAT GG Postgresql Procesar el trail remoto (recibido desde GG Classic) y aplicar los cambios en Postgresq rcdcora

(*) Los nombres de los elementos no deben superar los ocho caracteres.

La siguiente imagen describe el diseño del proceso, incluyendo los diferentes componentes:

Manos a la obra: implementando el proceso de replicación

Durante los siguientes puntos pasaremos a la práctica. Para que el post sea más legible, el detalle de cada paso lo encontraremos en el fichero Readme del repositorio asociado.

Creando la infraestructura base

Lo primero que tenemos que hacer es crear la infraestructura que soportará el caso de uso. Lo haremos sobre AWS, y está compuesta principalmente por:

El detalle de estos pasos lo encontraremos en el apartado del Readme correspondiente a la creación de la infraestructura.

Preparando las bases de datos para la replicación

Para que el proceso de replicación sea posible, es necesario configurar las bases de datos origen y destino.

Además, crearemos en cada una un usuario propio para GoldenGate (oggadm1) y le daremos los privilegios necesarios.

Para ejecutar este paso iremos al apartado del Readme correspondiente a la preparación de la base de datos origen para la replicación.

Si vemos el diagrama de arquitectura final, tendríamos los siguientes elementos implementados:

Instalando Oracle GoldenGate

Ya tenemos las bases de datos de origen y destino preparadas y las máquinas virtuales EC2 listas. Ahora instalaremos las dos versiones de Oracle GoldenGate, la correspondiente al lado origen para Oracle, y la correspondiente al lado destino para Postgresql.

Instalando Oracle GoldenGate Classic

Para instalar y configurar Oracle GoldenGate Classic para Oracle tenemos que seguir los pasos indicados en el apartado “Creando la infraestructura base” del fichero Readme del repositorio. En este apartado, vamos a ver los siguientes puntos:

Instalando Oracle GoldenGate for Postgresql

De forma similar al apartado anterior, para instalar y configurar Oracle GoldenGate Classic para Postgresql tenemos que seguir los pasos indicados en el apartado “Instalando Oracle GoldenGate Postgresql” del fichero Readme. En este apartado, vamos a ver los siguientes puntos:

En este punto, ya tenemos instalados y configurados todos los elementos necesarios para poder implementar un proceso de replicación:

Implementando el proceso de replicación

Una vez que tenemos creada la infraestructura y GoldenGate instalado en cada máquina EC2, tenemos que implementar el proceso de replicación que hemos diseñado y que consiste en dos etapas diferenciadas: carga inicial y proceso de replicación.

Carga inicial

Como se puede observar en la parte azul del diagrama anterior, el proceso consta de un Extract en origen y un Replicat en destino.

Para crear estos dos elementos, tenemos que seguir las instrucciones detalladas en apartado asociado a la carga inicial del fichero Readme.

Es importante destacar el punto en el que se decide si los datos van a la tabla de particulares o a la tabla de empresas. Esto, como se puede ver en los detalles de la implementación, se realiza en el componente replicat, mediante las siguientes líneas del fichero de parámetros:

map oracledb.customers, target particulares.customers, where (tipo = 1);
map oracledb.customers, target empresas.customers, where (tipo = 2);

Una vez creados los elementos asociados a la carga inicial, estamos en el siguiente punto:

Proceso de CDC

Antes de lanzarnos a crear el propio proceso de CDC vamos a introducir el concepto de System Change Number o SCN.

System Change Number (SCN)

La base de datos Oracle utiliza un concepto llamado SCN (System Change Number). El SCN es similar a un timestamp, para mantener el orden de las transacciones que ocurren en la base de datos y así poder mantener la característica ACID.

Realmente SCN es un número que mantiene de forma interna la base de datos. Cada vez que se produce un commit, rollback o un checkpoint, se incrementa. Por lo tanto, cada SCN está asociado a un conjunto de cambios en un punto temporal. Si un SCN es mayor que otro SCN, quiere decir que corresponde a una transacción efectuada en un momento temporal posterior.

Los cambios realizados en la base de datos se escriben en los ficheros de log y se asocian a un SCN. Las entradas entre dos SCNs consecutivos pertenecen a una misma transacción.

El SCN será utilizado en el proceso de replicación para indicar a partir de qué transacción comienza a capturar información.

Implementando el proceso de CDC

Ahora sí, vamos a implementar los elementos que componen el proceso de replicación de cambios. Para crear estos dos elementos, tenemos que seguir las instrucciones detalladas en apartado asociado al proceso de replicación del fichero Readme.

Una vez finalizada esta implementación, ya tenemos todo el proceso completo:

Probando el proceso de replicación

Una vez que hemos implementado todos los pasos, solo nos queda probar el proceso de replicación en tiempo real, incluyendo la carga inicial y el proceso de replicación en sí.

Realizaremos pruebas de inserción, actualización y eliminación de datos sobre el origen (Oracle) comprobando después que las acciones realizadas se propagan a la base de datos Postgresql, ya que es una replicación unidireccional.

Para realizar este proceso, al igual que en apartados anteriores, nos vamos a apoyar en el apartado de pruebas del proceso de replicación explicado en detalle en el fichero Readme del repositorio de código.

Destruyendo la infraestructura

Una vez terminado el caso de uso, podemos proceder a la destrucción de la infraestructura que hemos creado en AWS. Para ello, realizamos los pasos explicados en el apartado correspondiente a la destrucción del entorno del fichero Readme.

Conclusión

En este post hemos visto cómo se puede usar Oracle GoldenGate para replicar datos desde un origen (Oracle) a varios destinos (en nuestro caso, dos esquemas diferentes).

Mediante esta replicación, se consigue satisfacer el requisito que nos había impuesto Negocio de dividir el modelo de datos actual, que contiene tanto datos de particulares y empresas, en dos modelos diferentes para que puedan evolucionar de forma independiente.

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.