Cómo sincronizar su base de datos Oracle on-premise en AWS

Observando el desarrollo de software corporativo desde la primera fila durante dos décadas, la tendencia innegable de los últimos años es clara: trasladar las bases de datos a la nube.

Ya he participado en algunos proyectos de migración, en los que el objetivo era llevar la base de datos local existente a la base de datos en la nube de Amazon Web Services (AWS). Mientras que en los materiales de documentación de AWS, aprenderá lo fácil que puede ser, estoy aquí para decirle que la ejecución de un plan de este tipo no siempre es fácil, y hay casos en los que puede fallar.

En este post, cubriré la experiencia del mundo real para el siguiente caso:

• La Fuente: Aunque, en teoría, no importa realmente cuál sea su fuente (puede utilizar un enfoque muy similar para la mayoría de las BD más populares), Oracle fue el sistema de base de datos elegido en las grandes empresas corporativas durante muchos años, y es ahí donde me centraré.
• El objetivo: No hay por qué ser específico en este aspecto. Puede elegir cualquier base de datos de destino en AWS, y el enfoque seguirá encajando.
• El Modo: Puede tener una actualización completa o incremental. Una carga de datos por lotes (los estados de origen y destino se retrasan) o una carga de datos (casi) en tiempo real. Ambas se tratarán aquí.
• La frecuencia: Puede que desee una migración única seguida de un cambio completo a la nube o que requiera algún periodo de transición y tener los datos actualizados en ambos lados simultáneamente, lo que implica desarrollar una sincronización diaria entre on-premise y AWS. Lo primero es más sencillo y tiene mucho más sentido, pero lo segundo se solicita con más frecuencia y tiene muchos más puntos de ruptura. Cubriré ambas aquí.

Descripción del problema

El requisito suele ser sencillo:

Queremos empezar a desarrollar servicios dentro de AWS, así que por favor copie todos nuestros datos en la base de datos “ABC”. Rápido y sencillo. Ahora necesitamos utilizar los datos dentro de AWS. Más adelante, averiguaremos qué partes del diseño de la base de datos debemos cambiar para adaptarlas a nuestras actividades.

Antes de seguir adelante, hay que tener en cuenta una cosa:

• No se deje llevar demasiado rápido por la idea de “copiar lo que tenemos y ocuparnos de ello más tarde”. Quiero decir, sí, esto es lo más fácil que se puede hacer, y se hará rápidamente, pero esto tiene el potencial de crear un problema arquitectónico tan fundamental que será imposible de arreglar más tarde sin una refactorización seria de la mayor parte de la nueva plataforma en nube. Imagínese que el ecosistema de la nube es completamente diferente al de las instalaciones. Con el tiempo se introducirán varios servicios nuevos. Naturalmente, la gente empezará a utilizar los mismos de forma muy diferente. Casi nunca es una buena idea replicar el estado on-premise en la nube de forma 1:1. Puede que lo sea en su caso particular, pero asegúrese de comprobarlo dos veces.
• Cuestione el requisito con algunas dudas significativas como
  • ¿Quién será el usuario típico que utilizará la nueva plataforma? Mientras que en las instalaciones puede ser un usuario empresarial transaccional, en la nube puede ser un científico de datos o un analista de almacenes de datos, o el usuario principal de los datos puede ser un servicio (por ejemplo, Databricks, Glue, modelos de aprendizaje automático, etc.).
  • ¿Se espera que los trabajos cotidianos habituales permanezcan incluso después de la transición a la nube? Si no es así, ¿cómo se espera que cambien?
  • ¿Prevé un crecimiento sustancial de los datos a lo largo del tiempo? Lo más probable es que la respuesta sea afirmativa, ya que esa suele ser la razón más importante para migrar a la nube. Un nuevo modelo de datos deberá estar preparado para ello.
• Prevea algunas consultas generales y anticipadas que la nueva base de datos recibirá de los usuarios. Esto definirá cuánto deberá cambiar el modelo de datos existente para seguir siendo relevante para el rendimiento.

Puesta en marcha de la migración

Una vez elegida la base de datos de destino y discutido satisfactoriamente el modelo de datos, el siguiente paso es familiarizarse con la herramienta de conversión de esquemas de AWS. Existen varias áreas en las que esta herramienta puede servir:

1. Analizar y extraer el modelo de datos de origen. SCT leerá lo que hay en la base de datos on-premise actual y generará un modelo de datos de origen para comenzar.
2. Sugerir una estructura de modelo de datos de destino basada en la base de datos de destino.
3. Generará scripts de despliegue de la base de datos de destino para instalar el modelo de datos de destino (basándose en lo que la herramienta haya averiguado de la base de datos de origen). Esto generará scripts de despliegue y, tras su ejecución, la base de datos en la nube estará lista para la carga de datos desde la base de datos local.

Ahora hay algunos consejos para utilizar la herramienta de conversión de esquemas.

En primer lugar, casi nunca debería utilizar directamente el resultado. Yo lo consideraría más bien como resultados de referencia, a partir de los cuales deberá realizar sus ajustes en función de su comprensión y finalidad de los datos y de la forma en que éstos se utilizarán en la nube.

En segundo lugar, antes, las tablas probablemente eran seleccionadas por usuarios que esperaban resultados breves y rápidos sobre alguna entidad concreta del dominio de datos. Pero ahora, los datos podrían seleccionarse con fines analíticos. Por ejemplo, los índices de la base de datos que antes funcionaban en la base de datos local ahora serán inútiles y definitivamente no mejorarán el rendimiento del sistema de BD relacionado con este nuevo uso. Del mismo modo, es posible que desee particionar los datos de forma diferente en el sistema de destino, tal y como se hacía antes en el sistema de origen.

Además, podría ser bueno considerar hacer algunas transformaciones de datos durante el proceso de migración, lo que básicamente significa cambiar el modelo de datos de destino para algunas tablas (para que ya no sean copias 1:1). Más adelante, será necesario implementar las reglas de transformación en la herramienta de migración.

Configuración de la herramienta de migración

Si las bases de datos de origen y de destino son del mismo tipo (por ejemplo, Oracle on-premise frente a Oracle en AWS, PostgreSQL frente a Aurora Postgresql, etc.), entonces lo mejor es utilizar una herramienta de migración dedicada que la base de datos concreta soporte de forma nativa (por ejemplo, exportaciones e importaciones de bombas de datos, Oracle Goldengate, etc.).

Sin embargo, en la mayoría de los casos, la base de datos de origen y la de destino no serán compatibles, y entonces la herramienta de elección obvia será AWS Database Migration Service.

AWS DMS permite básicamente configurar una lista de tareas a nivel de tabla, que definirá:

• ¿Cuál es exactamente la base de datos de origen y la tabla a la que se va a conectar?
• Especificaciones de sentencias que se utilizarán para obtener los datos para la tabla de destino.
• Herramientas de transformación (si las hay), que definirán cómo se mapearán los datos de origen en datos de la tabla de destino (si no son 1:1).
• ¿Cuál es la base de datos y la tabla de destino exactas en las que se cargarán los datos?

La configuración de las tareas DMS se realiza en algún formato de fácil uso como JSON.

Ahora, en el escenario más sencillo, todo lo que necesita hacer es ejecutar los scripts de despliegue en la base de datos de destino e iniciar la tarea DMS. Pero hay mucho más que eso.

Migración completa de datos de una sola vez

El caso más sencillo de ejecutar es cuando la solicitud consiste en trasladar toda la base de datos una sola vez a la base de datos en la nube de destino. Entonces, básicamente, todo lo que hay que hacer será lo siguiente

1. Defina la tarea DMS para cada tabla de origen.
2. Asegúrese de especificar correctamente la configuración de las tareas DMS. Esto significa establecer un paralelismo razonable, variables de almacenamiento en caché, configuración del servidor DMS, dimensionamiento del clúster DMS, etc. Esta suele ser la fase que más tiempo consume, ya que requiere pruebas exhaustivas y un ajuste fino del estado óptimo de la configuración.
3. Asegúrese de que cada tabla de destino se crea (vacía) en la base de datos de destino con la estructura de tablas esperada.
4. Programe una ventana temporal dentro de la cual se realizará la migración de datos. Antes, obviamente, asegúrese (realizando pruebas de rendimiento) de que la ventana de tiempo será suficiente para que la migración se complete. Durante la migración propiamente dicha, la base de datos de origen podría verse restringida desde el punto de vista del rendimiento. Además, se espera que la base de datos de origen no cambie durante el tiempo que dure la migración. De lo contrario, los datos migrados podrían ser diferentes de los almacenados en la base de datos de origen una vez realizada la migración.

Si la configuración de DMS se hace bien, no ocurrirá nada malo en este escenario. Todas y cada una de las tablas de origen serán recogidas y copiadas en la base de datos de destino de AWS. Las únicas preocupaciones serán el rendimiento de la actividad y asegurarse de que el dimensionamiento es correcto en cada paso para que no falle por falta de espacio de almacenamiento.

Sincronización diaria incremental

Aquí es donde las cosas empiezan a complicarse. Si el mundo fuera ideal, probablemente funcionaría bien todo el tiempo. Pero el mundo nunca es ideal.

El DMS puede configurarse para funcionar en dos modos:

• Carga completa – modo por defecto descrito y utilizado anteriormente. Las tareas DMS se inician cuando usted las inicia o cuando están programadas para iniciarse. Una vez finalizadas, las tareas DMS están terminadas.
• Captura de datos de cambios (CDC) – en este modo, las tareas DMS se ejecutan continuamente. DMS explora la base de datos de origen en busca de un cambio a nivel de tabla. Si se produce el cambio, intenta replicarlo inmediatamente en la base de datos de destino basándose en la configuración dentro de la tarea DMS relacionada con la tabla modificada.

Si opta por el CDC, tendrá que hacer otra elección, a saber, cómo extraerá el CDC los cambios delta de la base de datos de origen.

#1. Lector de Redo Logs de Oracle

Una opción es elegir el lector nativo de redo logs de base de datos de Oracle, que CDC puede utilizar para obtener los datos modificados y, basándose en los últimos cambios, replicar los mismos cambios en la base de datos de destino.

Aunque esto pueda parecer una opción obvia si se trata de Oracle como fuente, hay una trampa: El lector de redo logs de Oracle utiliza el cluster Oracle de origen y, por tanto, afecta directamente a todas las demás actividades que se ejecutan en la base de datos (de hecho, crea directamente sesiones activas en la base de datos).

Cuantas más tareas DMS tenga configuradas (o cuantos más clústeres DMS tenga en paralelo), más probable será que necesite aumentar el tamaño del clúster Oracle: básicamente, ajustar el escalado vertical de su clúster primario de base de datos Oracle. Esto seguramente influirá en los costes totales de la solución, más aún si la sincronización diaria va a permanecer en el proyecto durante un largo periodo de tiempo.

#2. AWS DMS Log Miner

A diferencia de la opción anterior, se trata de una solución nativa de AWS para el mismo problema. En este caso, DMS no afecta a la base de datos Oracle de origen. En su lugar, copia los redo logs de Oracle en el clúster DMS y realiza todo el procesamiento allí. Aunque ahorra recursos de Oracle, es la solución más lenta, ya que intervienen más operaciones. Y también, como es fácil suponer, el lector personalizado para redo logs de Oracle es probablemente más lento en su trabajo que el lector nativo de Oracle.

Dependiendo del tamaño de la base de datos de origen y del número de cambios diarios que se produzcan en ella, en el mejor de los casos, podría acabar con una sincronización incremental casi en tiempo real de los datos de la base de datos Oracle on-premise en la base de datos en la nube de AWS.

En cualquier otro escenario, seguirá sin ser una sincronización casi en tiempo real, pero puede intentar acercarse lo máximo posible al retraso aceptado (entre el origen y el destino) ajustando la configuración del rendimiento y el paralelismo de los clústeres de origen y destino o experimentando con la cantidad de tareas DMS y su distribución entre las instancias CDC.

Además, es posible que desee saber qué cambios en la tabla de origen admite CDC (como la adición de una columna, por ejemplo), ya que no se admiten todos los cambios posibles. En algunos casos, la única forma es realizar el cambio en la tabla de destino manualmente y reiniciar la tarea CDC desde cero (perdiendo por el camino todos los datos existentes en la base de datos de destino).

Cuando las cosas van mal, no importa qué

Aprendí esto por las malas, pero hay un escenario específico relacionado con el DMS en el que la promesa de la replicación diaria es difícil de cumplir.

El DMS sólo puede procesar los redo logs con cierta velocidad definida. No importa si hay más instancias de DMS ejecutando sus tareas. Aún así, cada instancia de DMS lee los redo logs sólo con una única velocidad definida, y cada una de ellas debe leerlos enteros. Incluso no importa si utiliza los redo logs de Oracle o el log miner de AWS. Ambos tienen este límite.

Si la base de datos de origen incluye un gran número de cambios en un día que los registros de rehacer de Oracle se vuelven realmente locamente grandes (como 500 GB de tamaño) cada día, CDC simplemente no va a funcionar. La replicación no se completará antes del final del día. Llevará parte del trabajo no procesado al día siguiente, donde ya está esperando un nuevo conjunto de cambios que replicar. La cantidad de datos sin procesar no hará más que crecer de un día para otro.

En este caso concreto, CDC no era una opción (después de muchas pruebas de rendimiento e intentos que ejecutamos). La única forma de garantizar que al menos todos los cambios delta del día en curso se replicaran el mismo día era enfocarlo así:

• Separar las tablas realmente grandes que no se utilizan tan a menudo y replicarlas sólo una vez por semana (por ejemplo, durante los fines de semana).
• Configure la replicación de las tablas no tan grandes, pero todavía grandes, para que se dividan entre varias tareas DMS; finalmente, una tabla fue migrada por 10 o más tareas DMS separadas en paralelo, asegurándose de que la división de los datos entre las tareas DMS es distinta (en este caso se trata de codificación personalizada) y ejecútelas diariamente.
• Añada más instancias (hasta 4 en este caso) de DMS y divida las tareas DMS entre ellas de manera uniforme, es decir, no sólo por el número de las tablas sino también por el tamaño.

Básicamente, utilizamos el modo de carga completa de DMS para replicar los datos diarios porque era la única forma de conseguir que la replicación de datos se completara al menos el mismo día.

No es una solución perfecta, pero sigue ahí, e incluso después de muchos años, sigue funcionando de la misma manera. Así que, tal vez no sea tan mala solución después de todo. 😃