Replicación unidireccional con Oracle GoldenGate.

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:

• Crear un modelo de lectura para cada tipo. Más adelante podrán incluir operaciones de escritura pero, de momento, la responsabilidad del dato (y fuente de verdad) se establece en Oracle.
• Se quiere aprovechar para reducir la carga de la base de datos Oracle y su coste de operación. Para ello, se pasará a una base de datos Postgresql en Cloud y auto-gestionada.

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:

• La clave primaria de la tabla CUSTOMERS de Oracle es un entero basado en una secuencia.
• La gestión (e incremento) de esta clave es la misma, tanto si se inserta un cliente particular como un cliente empresa. Es decir, se va a incrementar en una unidad cada vez que se produzca un insert, independientemente del tipo.
• En destino vamos a manejar dos tablas (cada una con una columna ID), que actúa de clave primaria y que se auto-incrementa en cada inserción.

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:

• Carga inicial: replicaremos todos los datos existentes en la tabla CUSTOMERS de Oracle en las dos tablas destino en Postgresql, cada una en un esquema.
• CDC: aplicaremos los cambios que se produzcan en el origen (Oracle) en el esquema y tabla correspondiente del destino, Postgresql.

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:

(*) 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:

• Una base de datos Oracle con una tabla para clientes.
• Una base de datos Postgresql con el nuevo modelo (una tabla para cada tipo).
• Dos máquinas EC2, para separar GoldenGate origen (Oracle) y destino (Postgresql).

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:

• Instalación y configuración de Oracle GoldenGate Classic.
• Configuración de acceso a la base de datos origen (Oracle).
• Creación del almacén de credenciales.
• Inicialización del componente Manager.

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:

• Instalación y configuración de Oracle GoldenGate Classic for Postgresql.
• Configuración de acceso a la base de datos destino (Postgresql).
• Inicialización del componente Manager.

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.