systemdba

Un reinicio no programado (uncontrolled reboot) en un servidor con Red Hat Enterprise Linux 9 es uno de los escenarios más críticos para Oracle GoldenGate 23ai. Recientemente, enfrentamos un incidente donde, tras un fallo del sistema, los procesos Replicat hacia Kafka quedaron inoperativos debido a la corrupción de sus archivos de estado.

A continuación, detallo el análisis de la falla y el procedimiento de recuperación manual aplicado.

El Problema: Archivos de Checkpoint Corruptos

Cuando un servidor falla abruptamente, los procesos que escriben activamente en disco pueden dejar archivos truncados. En los adaptadores de Big Data, esto afecta específicamente a los archivos de estado del Java Adapter.

Síntomas en el archivo de reporte (Report File):

Al intentar iniciar el Replicat, el proceso se detiene (ABEND) inmediatamente con la siguiente excepción:

ERROR OGG-15051 Java or JNI exception: java.lang.ExceptionInInitializerError.
Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map due to end-of-input
at oracle.goldengate.checkpoint.CheckpointManager.deserialize(CheckpointManager.java:443)

Análisis de Causa Raíz (Root Cause Analysis)

El motor de Java utiliza archivos en formato .json para persistir el progreso del envío de mensajes hacia Kafka. El error No content to map indica que el archivo existe físicamente pero tiene un tamaño de 0 bytes. El parser de Java no puede interpretar un archivo vacío, lo que impide que el Replicat inicialice su manejador de checkpoints (Checkpoint Manager).

Procedimiento de Recuperación: Intervención Manual

Dado que el mecanismo de recuperación automática falla al detectar metadatos corruptos, es necesario intervenir manualmente para limpiar el entorno y realizar un reposicionamiento de la lectura en el Trail File.

Paso 1: Identificación y Respaldo (Backup)

El primer paso es localizar los archivos de estado dañados. En RHEL, podemos identificarlos por su tamaño:

1. Localizar los archivos .json con tamaño 0.
2. Crear una copia segura (safe copy) en una ubicación externa.
3. Eliminar los archivos vacíos del directorio de trabajo de GoldenGate para desbloquear la inicialización de Java.

Paso 2: Determinar el Punto de Reinicio

Al eliminar el archivo .json, el Replicat pierde su referencia exacta de entrega hacia Kafka. Para evitar una lectura desde el inicio del Trail, debemos consultar el checkpoint nativo de la capa de Core (C++):

-- Ejecutar en Admin Client o GGSCI
INFO REPLICAT <Nombre_Replicat>, SHOWCH

Es necesario capturar el Log Sequence Number (extseqno) y el RBA (extrbao) de la sección “Current Checkpoint”.

Paso 3: Reposicionamiento y Arranque (Start)

Con la información obtenida, procedemos a forzar la posición de lectura y reiniciar el servicio:

-- Reposicionar el Replicat al último checkpoint válido
ALTER REPLICAT <Nombre_Replicat>, EXTRSEQNO <Número>, EXTRBAO <RBA>
-- Iniciar el proceso
START REPLICAT <Nombre_Replicat>

En implementaciones de Big Data sobre RHEL 9, la integridad de los archivos de estado es más vulnerable que en las bases de datos relacionales tradicionales, ya que no existe una CHECKPOINTTABLE transaccional en el destino.

La eliminación de los archivos corruptos seguida de un Manual Alter es la ruta más efectiva para restaurar el servicio. Es importante notar que, al realizar este procedimiento, existe un riesgo mínimo de duplicidad de datos en el destino, el cual debe ser gestionado mediante configuraciones de idempotencia en el productor o lógica de filtrado en el consumidor.