Migración de bases de datos: Conceptos y principios (parte 1)

Last reviewed 2024-03-07 UTC

En este documento, se presentan los conceptos, los principios, la terminología y la arquitectura de la migración de bases de datos de tiempo de inactividad casi nulo para los arquitectos de la nube que migran bases de datos a Google Cloud desde otros o entornos locales o de nube.

Este documento es la parte 1 de una serie de dos partes. En la parte 2, se analiza la configuración y la ejecución del proceso de migración, incluidos los casos de fallas.

La migración de bases de datos es el proceso mediante el que se migran datos de una o más bases de datos de origen a una o más bases de datos de destino mediante un servicio de migración de bases de datos. Cuando finaliza una migración, el conjunto de datos en las bases de datos de origen reside completo, aunque posiblemente reestructurado, en las bases de datos de destino. Los clientes que accedían a las bases de datos de origen se pasan a las bases de datos de destino, y las bases de datos de origen se desactivan.

En el siguiente diagrama, se ilustra este proceso de migración de las bases de datos.

Flujo de datos de las bases de datos de origen a las de destino a través del servicio de migración

En este documento, se describe la migración de bases de datos desde el punto de vista arquitectónico:

  • Los servicios y tecnologías involucrados en la migración de la base de datos
  • Las diferencias entre la migración de bases de datos homogéneas y heterogéneas
  • Las compensaciones y la selección de una tolerancia para el tiempo de inactividad de migración
  • Una arquitectura de configuración que admite un resguardo si se producen errores imprevistos durante una migración

En este documento, no se describe cómo configurar una tecnología de migración de base de datos en particular. En su lugar, presenta los principios, conceptos y fundamentos de la migración de bases de datos.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura de migración de base de datos genérica.

Arquitectura del servicio de migración que accede a las bases de datos de origen y de destino

Un servicio de migración de bases de datos se ejecuta en Google Cloud y accede a las bases de datos de origen y de destino. Se representan dos variantes: (a) muestra la migración de una base de datos de origen desde un centro de datos local o una nube remota a una base de datos administrada como Spanner; (b) muestra una migración a una base de datos en Compute Engine.

Aunque las bases de datos de destino son de diferente tipo (administrado y no administrado) y configuración, la arquitectura y la configuración de migración de la base de datos es la misma para ambos casos.

Terminología

Los términos de migración de datos más importantes para estos documentos se definen de la siguiente manera:

Base de datos de origen: Es una base de datos que contiene datos para migrar a una o más bases de datos de destino.

Base de datos de destino: Es una base de datos que recibe datos migrados desde una o más bases de datos de origen.

Migración de bases de datos: Es una migración de datos desde bases de datos de origen hacia bases de datos de destino con el objetivo de desactivar los sistemas de bases de datos de origen una vez que se completa la migración. Se migra el conjunto de datos completo o un subconjunto.

Migración homogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de origen y de destino pertenecen al mismo sistema de administración de bases de datos, del mismo proveedor.

Migración heterogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de datos de origen y de destino pertenecen a diferentes sistemas de administración de bases de datos, de diferentes proveedores.

Sistema de migración de bases de datos: Es un sistema o servicio de software que se conecta a bases de datos de origen y de destino y realiza migraciones de datos desde bases de datos de origen hacia bases de datos de destino.

Proceso de migración de datos: Es un proceso configurado o implementado que ejecuta el sistema de migración de datos para transferir datos de bases de datos de origen a bases de destino, durante el cual es posible que los datos se transformen.

Replicación de base de datos: Es una transferencia continua de datos desde bases de datos de origen hacia bases de datos de destino sin la intención de desactivar las bases de datos de origen. La replicación de bases de datos (a veces llamada transmisión de bases de datos) es un proceso continuo.

Clasificación de las migraciones de bases de datos

Existen diferentes tipos de migraciones de bases de datos que pertenecen a diferentes clases. En esta sección, se describen los criterios que definen esas clases.

Comparación entre la replicación y la migración

En una migración de bases de datos, mueves datos de bases de datos de origen a bases de datos de destino. Una vez que los datos se migran por completo, borras las bases de datos de origen y redireccionas el acceso de los clientes a las bases de datos de destino. A veces, puedes mantener las bases de datos de origen como una medida de resguardo en caso de que surjan problemas imprevistos con las bases de datos de destino. Sin embargo, una vez que las bases de datos de destino funcionan de manera confiable, debes borrar las bases de datos de origen.

En cambio, con la replicación de base de datos, transfieres datos de forma continua desde las bases de datos de origen hacia las bases de datos de destino, sin borrar las de origen. A veces, la replicación de bases de datos se conoce como transmisión de bases de datos. Si bien hay una hora de inicio definida, por lo general, no se establece una hora de finalización. La replicación puede detenerse o convertirse en una migración.

En este documento, solo se analiza la migración de bases de datos.

Comparación entre la migración parcial y la migración completa

La migración de bases de datos se entiende como una transferencia de datos completa y coherente. Debes definir que el conjunto de datos inicial se transfiera como una base de datos completa o parcial (un subconjunto de los datos en la base de datos), además de que se transfiera cada cambio posterior confirmado en el sistema de base de datos de origen.

Comparación entre la migración heterogénea y la migración homogénea

Una migración de bases de datos homogénea es una migración entre bases de datos de origen y de destino con la misma tecnología de base de datos, por ejemplo, una migración desde una base de datos de MySQL hacia una de MySQL, o desde una base de datos de Oracle® hacia una de Oracle. Las migraciones homogéneas también incluyen migraciones entre un sistema de base de datos alojado en sí mismo, como PostgreSQL, y una versión administrada, como Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL.

En una migración de bases de datos homogénea, es probable que los esquemas de las bases de datos de origen y de destino sean idénticos. Si los esquemas son diferentes, los datos de las bases de datos de origen deben transformarse durante la migración.

La migración de base de datos heterogénea es una migración entre bases de datos de origen y de destino con diferentes tecnologías de base de datos, por ejemplo, desde una base de datos de Oracle hacia una de Spanner. La migración de base de datos heterogénea puede ser entre los mismos modelos de datos (por ejemplo, de un modelo relacional a uno relacional) o entre diferentes modelos de datos (por ejemplo, de un modelo relacional a uno de clave-valor).

La migración entre diferentes tecnologías de base de datos no siempre implica diferentes modelos de datos. Por ejemplo, Oracle, MySQL, PostgreSQL y Spanner admiten el modelo de datos relacionales. Sin embargo, las bases de datos de varios modelos, como Oracle, MySQL o PostgreSQL, admiten diferentes modelos de datos. Los datos almacenados como documentos JSON en una base de datos de varios modelos se pueden migrar a MongoDB con poca o ninguna transformación, ya que el modelo de datos es el mismo en las bases de datos de origen y de destino.

Aunque la distinción entre la migración homogénea y heterogénea se basa en tecnologías de base de datos, una categorización alternativa se basa en los modelos de bases de datos involucrados. Por ejemplo, una migración de una base de datos de Oracle a una de Spanner es homogénea si ambas usan el modelo de datos relacionales; una migración es heterogénea si, por ejemplo, los datos almacenados como objetos JSON en Oracle se migran a un modelo relacional en Spanner.

La categorización de las migraciones según el modelo de datos expresa con mayor precisión la complejidad y el esfuerzo necesarios para migrar los datos que cuando la categorización se basa en el sistema de base de datos involucrado. Sin embargo, debido a que la categorización que más se usa en la industria es la basada en los sistemas de bases de datos involucrados, las secciones restantes se enfocan en esa distinción.

Tiempo de inactividad de la migración: nulo frente a casi nulo

Después de migrar un conjunto de datos de la base de datos de origen a la de destino de forma correcta, debes cambiar el acceso del cliente a la base de datos de destino y borrar la base de datos de origen.

El cambio de clientes de las bases de datos de origen a las de destino implica varios procesos:

  • Para continuar con el procesamiento, los clientes deben cerrar las conexiones existentes a las bases de datos de origen y crear conexiones nuevas a las bases de datos de destino. Lo ideal es que las conexiones se cierren de forma correcta para que no debas revertir las transacciones en curso sin necesidad.
  • Después de cerrar las conexiones en las bases de datos de origen, debes migrar los cambios restantes de las bases de datos de origen a las de destino (llamado desvío) para asegurarte de que se capten todos los cambios.
  • Es posible que debas probar las bases de datos de destino para garantizar que funcionen, además de comprobar que los clientes también funcionen y operen dentro de sus objetivos de nivel de servicio (SLO) definidos.

En una migración, es imposible lograr un tiempo de inactividad nulo para los clientes. A veces, los clientes no pueden procesar solicitudes. Sin embargo, puedes minimizar el tiempo en el que los clientes no pueden procesar solicitudes de varias maneras (tiempo de inactividad casi nulo):

  • Puedes iniciar tus clientes de prueba en modo de solo lectura en las bases de datos de destino mucho antes de cambiar los clientes. Con este método, las pruebas son simultáneas con la migración.
  • Puedes configurar la cantidad de datos que se migrarán (es decir, que estarán en tránsito entre las bases de datos de origen y de destino) para que sea lo más pequeña posible cuando se acerque el período de cambio. Este paso reduce el tiempo de desvío porque hay menos diferencias entre las bases de datos de origen y las de destino.
  • Si los clientes nuevos que operan en las bases de datos de destino pueden iniciarse de forma simultánea junto con los clientes existentes que operan en las bases de datos de origen, puedes acortar el tiempo de cambio, ya que los clientes nuevos están listos para ejecutarse en cuanto se desvían todos los datos.

Si bien es poco realista esperar un tiempo de inactividad nulo durante un cambio, puedes minimizar el tiempo de inactividad si inicias actividades en simultáneo con la migración de datos continua cuando sea posible.

En algunos casos de migración de bases de datos, se acepta un tiempo de inactividad significativo. Por lo general, esto se debe a requisitos empresariales. En tales casos, puedes simplificar el método que usas. Por ejemplo, con una migración de bases de datos homogénea, es posible que no necesites modificar los datos. La importación y exportación, así como la creación de copias de seguridad y el restablecimiento, son métodos perfectos. Con las migraciones heterogéneas, el sistema de migración de bases de datos no tiene que lidiar con las actualizaciones de los sistemas de base de datos durante la migración.

Sin embargo, debes establecer un tiempo de inactividad aceptable que sea tan largo como para que ocurran la migración de la base de datos y las pruebas de seguimiento. Si este tiempo de inactividad no se puede establecer de forma clara o es demasiado largo, debes planificar una migración que incluya un tiempo de inactividad mínimo.

Cardinalidad de migración de bases de datos

En muchos casos, la migración de bases de datos se realiza entre una sola base de datos de origen y una única base de datos de destino. En tales casos, la cardinalidad es 1:1 (mapeo directo). Es decir, una base de datos de origen se migra sin cambios a una base de datos de destino.

Sin embargo, el mapeo directo no es la única posibilidad. Estas son otras cardinalidades posibles:

  • Consolidación (n:1). En una consolidación, migras datos de varias bases de datos de origen a una cantidad menor de bases de datos de destino (o incluso a solo una). Puedes usar este método para simplificar la administración de bases de datos o emplear una base de datos de destino que pueda escalar.
  • Distribución (1:n). En una distribución, migras datos de una base de datos de origen a varias bases de datos de destino. Por ejemplo, puedes usar este método cuando necesites migrar una gran base de datos centralizada que contenga datos regionales a varias bases de datos de destino regionales.
  • Redistribución (n:m). En una redistribución, migras datos de varias bases de datos de origen a varias bases de datos de destino. Puedes usar este método cuando tienes bases de datos fragmentadas con fragmentos de tamaños muy diferentes. La redistribución reparte los datos fragmentados de manera uniforme en varias bases de datos de destino que representan los fragmentos.

La migración de la base de datos brinda la oportunidad de rediseñar y de implementar la arquitectura de la base de datos, además de solo migrar datos.

Coherencia de la migración

Se espera que la migración de una base de datos sea coherente. En el contexto de la migración, coherente significa lo siguiente:

  • Completa. Todos los datos que se especifican para migrar se migran realmente. Los datos especificados pueden ser todos los datos en una base de datos de origen o un subconjunto de datos.
  • Sin duplicados. Cada dato se migra solo una vez. No se ingresan datos duplicados en la base de datos de destino.
  • Ordenada. Los cambios de datos en la base de datos de origen se aplican a la base de datos de destino en el mismo orden en que ocurrieron los cambios en la base de datos de origen. Este aspecto es esencial para garantizar la coherencia de los datos.

Otra forma de describir la coherencia de la migración es que, después de que se completa una migración, el estado de los datos de las bases de datos de origen y de destino debe ser equivalente. Por ejemplo, en una migración homogénea que implica el mapeo directo de una base de datos relacional, las mismas tablas y filas deben existir en las bases de datos de origen y de destino.

Esta forma alternativa de describir la coherencia de la migración es importante porque no todas las migraciones de datos se basan en la aplicación secuencial de transacciones de la base de datos de origen a la de destino. Por ejemplo, puedes crear una copia de seguridad de la base de datos de origen y usar esta copia para restablecer el contenido de la base de datos de origen en la de destino (cuando haya el suficiente tiempo de inactividad disponible).

Migración activa-pasiva y migración activa-activa

Una distinción importante es si las bases de datos de origen y de destino están abiertas para modificar el procesamiento de consultas. En una migración de base de datos activa-pasiva, las bases de datos de origen se pueden modificar durante la migración, mientras que las bases de datos de destino permiten nada más que el acceso de solo lectura.

Una migración activa-activa admite que los clientes escriban en las bases de datos de origen y de destino durante la migración. En este tipo de migración, pueden ocurrir conflictos. Por ejemplo, si el mismo elemento de datos en las bases de datos de origen y de destino se modifica de modo que se genere un conflicto semántico, es posible que debas ejecutar reglas de resolución de conflictos para solucionar el conflicto.

En una migración activa-activa, debes poder resolver todos los conflictos de datos mediante reglas de resolución de conflictos. Si no puedes hacerlo, es posible que experimentes incoherencias en los datos.

Arquitectura de migración de bases de datos

Una arquitectura de migración de una base de datos describe los diversos componentes necesarios para ejecutar una migración de base de datos. En esta sección, se presenta una arquitectura de implementación genérica y se trata el sistema de migración de bases de datos como un componente independiente. También se analizan las características de un sistema de administración de bases de datos que admite la migración de datos, así como las propiedades no funcionales que son importantes para muchos casos de uso.

Arquitectura de implementación

Una migración de bases de datos puede ocurrir entre las bases de datos de origen y de destino ubicadas en cualquier entorno, como en diferentes nubes o entornos locales. Cada base de datos de origen y de destino puede estar en un entorno diferente. No es necesario que todas estén ubicadas en el mismo entorno.

En el siguiente diagrama, se muestra un ejemplo de una arquitectura de implementación que involucra varios entornos.

Arquitectura de migración que involucra centros de datos locales y en la nube

DB1 y DB2 son las dos bases de datos de origen, y DB3 y Spanner son las bases de datos de destino. En esta migración de bases de datos, se incluyen dos nubes y dos centros de datos locales. Las flechas representan las relaciones de invocación: el servicio de migración de bases de datos invoca a las interfaces de todas las bases de datos de origen y de destino.

Un caso especial que no se analiza aquí es la migración de datos de una base de datos a la misma base de datos. En este caso especial, se usa el sistema de migración de bases de datos solo para la transformación de datos, no con el objetivo de migrar datos entre sistemas diferentes en entornos diferentes.

En esencia, existen tres métodos para la migración de bases de datos, que se analizan en esta sección:

Sistema de migración de base de datos

El sistema de migración de bases de datos es el núcleo de la migración de bases de datos. El sistema ejecuta la extracción de datos desde las bases de datos de origen, transporta los datos a las bases de datos de destino y, de manera opcional, modifica los datos durante el envío. En esta sección, se realiza un análisis general de las funciones básicas del sistema de migración de bases de datos. Algunos ejemplos de sistemas de migración de bases de datos son Database Migration Service, Striim, Debezium, tcVision y Cloud Data Fusion.

Proceso de migración de datos

El componente básico principal de un sistema de migración de bases de datos es el proceso de migración de datos. Un desarrollador especifica el proceso de migración de datos, y este proceso define las bases de datos de origen de las que se extraen los datos, las bases de datos de destino a las que se migran los datos y cualquier lógica de modificación de datos que se aplique a los datos durante la migración.

Puedes especificar uno o más procesos de migración de datos y ejecutarlos de manera secuencial o simultánea, según las necesidades de la migración. Por ejemplo, si migras bases de datos independientes, los procesos de migración de datos correspondientes pueden ejecutarse en paralelo.

Inserción y extracción de datos

Puedes detectar cambios (inserciones, actualizaciones, eliminaciones) en un sistema de base de datos de dos maneras: mediante la captura de datos modificados (CDC) compatible con bases de datos y basada en un registro de transacciones, y por medio de consultas diferenciales de datos con la interfaz de consultas de un sistema de administración de bases de datos.

CDC basada en un registro de transacciones

La CDC compatible con bases de datos se basa en funciones de administración de bases de datos que son independientes de la interfaz de consultas. Un método se basa en los registros de transacciones (por ejemplo, el registro binario en MySQL). Un registro de transacciones contiene los cambios realizados en los datos en el orden correcto. El registro de transacciones se lee de forma continua, por lo que se pueden observar todos los cambios. Para la migración de bases de datos, este registro es muy útil, ya que la CDC garantiza que cada cambio sea visible y se migre a la base de datos de destino sin pérdidas y en el orden correcto.

La CDC es el método preferido para capturar cambios en un sistema de administración de bases de datos. La CDC está integrada en la base de datos y tiene el menor impacto de carga en el sistema.

Consultas diferenciales

Si no existe ninguna función del sistema de administración de bases de datos que admita la visualización de todos los cambios en el orden correcto, puedes usar una consulta diferencial como alternativa. En este método, cada elemento de datos en una base de datos obtiene un atributo adicional que contiene una marca de tiempo o un número de secuencia. Cada vez que se cambia el elemento de datos, se agrega la marca de tiempo del cambio o se aumenta el número de secuencia. Un algoritmo de sondeo lee todos los elementos de datos desde la última vez que se ejecutó o desde el último número de secuencia que usó. Una vez que el algoritmo de sondeo determina los cambios, registra la hora o el número de secuencia actual en su estado interno y, luego, pasa los cambios a la base de datos de destino.

Si bien este método funciona sin problemas para inserciones y actualizaciones, debes diseñar con cuidado las eliminaciones, ya que una eliminación quita un elemento de datos de la base de datos. Una vez que se borran los datos, es imposible que la aplicación de sondeo detecte que se realizó una eliminación. Debes implementar una eliminación mediante un campo de estado adicional (una marca de eliminación lógica) que indique que se borraron los datos. De manera alternativa, los elementos de datos borrados se pueden recopilar en una o más tablas, y la aplicación de sondeo accede a esas tablas para determinar si se borraron datos.

Para conocer las variantes de las consultas diferenciales, consulta Cambia la captura de datos.

Las consultas diferenciales son el método menos preferido porque implica cambios de esquema y de funciones. Si se consulta la base de datos, también se agrega una carga de consulta que no se relaciona con la ejecución de la lógica del cliente.

Adaptador y agente

El sistema de migración de bases de datos requiere acceso al origen y a los sistemas de bases de datos. Los adaptadores son la abstracción que encapsula las funciones de acceso. En la forma más simple, un adaptador puede ser un controlador de JDBC para insertar datos en una base de datos de destino compatible con JDBC. En un caso más complejo, un adaptador se ejecuta en el entorno de la base de datos de destino (a veces llamado agente) y accede a una interfaz de base de datos integrada, como archivos de registro. En un caso aún más complejo, un adaptador o agente interactúa con otro sistema de software, que, a su vez, accede a la base de datos. Por ejemplo, un agente accede a Oracle GoldenGate y, a su vez, accede a una base de datos de Oracle.

El adaptador o agente que accede a una base de datos de origen implementa la interfaz de CDC o la interfaz de consultas diferenciales, según el diseño del sistema de base de datos. En ambos casos, el adaptador o el agente proporcionan los cambios al sistema de migración de bases de datos, y este sistema no reconoce si los cambios fueron capturados por la CDC o por consultas diferenciales.

Modificación de datos

En algunos casos de uso, los datos se migran desde bases de datos de origen hacia bases de datos de destino sin modificar. Estas migraciones directas suelen ser homogéneas.

Sin embargo, muchos casos de uso requieren que se modifiquen los datos durante el proceso de migración. Por lo general, la modificación es obligatoria cuando hay diferencias en el esquema, diferencias en los valores de los datos u oportunidades para descartar datos durante la transición.

En las siguientes secciones, se analizan varios tipos de modificaciones que se pueden requerir en una migración de datos: transformación de datos, enriquecimiento o correlación de datos, y reducción o filtrado de datos.

Transformación de datos

La transformación de datos transforma algunos o todos los valores de datos de la base de datos de origen. Estos son algunos ejemplos:

  • Transformación del tipo de datos. A veces, los tipos de datos entre las bases de datos de origen y de destino no son equivalentes. En estos casos, la transformación de tipo de datos convierte el valor de origen en el valor de destino según las reglas de transformación de tipo. Por ejemplo, un tipo de marca de tiempo de la base de datos de origen podría transformarse en una string en la base de datos de destino.
  • Transformación de la estructura de los datos. La transformación de la estructura de los datos implica modificar la estructura en el mismo modelo de base de datos o entre diferentes modelos de base de datos. Por ejemplo, en un sistema relacional, una tabla de origen puede dividirse en dos tablas de destino, o varias tablas de origen pueden desnormalizarse en una tabla de destino mediante una unión. Una relación 1:n en la base de datos de origen puede transformarse en una relación superior/secundario en Spanner. Los documentos de un sistema de base de datos de documentos de origen pueden dividirse en un conjunto de filas relacionales en un sistema de destino.
  • Transformación del valor de los datos. La transformación del valor de los datos es independiente de la transformación del tipo de datos. La transformación del valor de los datos consiste en cambiar el valor sin cambiar el tipo de datos. Por ejemplo, una zona horaria local se convierte en la hora universal coordinada (UTC). O un código postal corto (cinco dígitos) que se representa como una string se convierte en un código postal extenso (cinco dígitos seguido de un guion y 4 dígitos, también conocido como ZIP+4).
Correlación y enriquecimiento de datos

La transformación de datos se aplica a los datos existentes sin hacer referencia a datos de referencia adicionales relacionados. Con el enriquecimiento de datos, se consultan datos adicionales para enriquecer los datos de origen antes de que se almacenen en la base de datos de destino.

  • Correlación de datos. Es posible correlacionar los datos de origen. Por ejemplo, puedes combinar datos de dos tablas en dos bases de datos de origen. En una base de datos de destino, por ejemplo, puedes relacionar un cliente con todos los pedidos en progreso, completados y cancelados en los cuales los datos del cliente y del pedido se originan a partir de dos bases de datos de origen diferentes.
  • Enriquecimiento de datos. Mediante el enriquecimiento de datos, se agregan datos de referencia. Por ejemplo, puedes enriquecer los registros que solo contienen un código postal si agregas el nombre de la ciudad correspondiente al código postal. Una tabla de referencia que contiene códigos postales y los nombres de las ciudades correspondientes es un conjunto de datos estático al que se accede para este caso de uso. Los datos de referencia también pueden ser dinámicos. Por ejemplo, puedes usar una lista de todos los clientes conocidos como datos de referencia.
Reducción y filtrado de datos

Otro tipo de transformación de datos consiste en reducir o filtrar los datos de origen antes de migrarlos a una base de datos de destino.

  • Reducción de datos. La reducción de datos consiste en quitar los atributos de un elemento de datos. Por ejemplo, si hay un código postal en un elemento de datos, es posible que el nombre de la ciudad correspondiente no sea obligatorio y se descarte, porque se puede volver a calcular o porque ya no es necesario. A veces, esta información se conserva por motivos relacionados con el historial, para registrar el nombre de la ciudad tal como lo ingresó el usuario, incluso si el nombre de la ciudad cambia en el tiempo.
  • Filtrado de datos. El filtrado de datos implica quitar un elemento de datos por completo. Por ejemplo, todos los pedidos cancelados pueden quitarse y no transferirse a la base de datos de destino.
Combinación o cambio de la combinación de los datos

Si los datos se migran desde bases de datos de origen distintas hacia bases de datos de destino diferentes, puede ser necesario combinar los datos de otra forma entre las bases de datos de origen y de destino.

Supongamos que los clientes y los pedidos se almacenan en dos bases de datos de origen diferentes. Una base de datos de origen contiene todos los pedidos, y una segunda base de datos de origen contiene todos los clientes. Después de la migración, los clientes y sus pedidos se almacenan en una relación 1:n dentro de un solo esquema de base de datos de destino (no en una sola base de datos de destino, sino en varias bases de datos de destino, cada una con una partición de los datos). Cada base de datos de destino representa una región y contiene todos los clientes con sus pedidos ubicados en esa región.

Selección de base de datos de destino

A menos que haya solo una base de datos de destino, cada elemento de datos que se migra debe enviarse a la base de datos de destino correcta. Estos son algunos métodos para seleccionar la base de datos de destino:

  • Selección basada en esquemas. La selección basada en esquemas determina la base de datos de destino según el esquema. Por ejemplo, todos los elementos de datos de una colección de clientes o todas las filas de una tabla de clientes se migran a la misma base de datos de destino que almacena la información de clientes, incluso si esta información estaba distribuida en varias bases de datos de origen.
  • Enrutamiento basado en el contenido. El enrutamiento basado en el contenido (por ejemplo, con un router basado en el contenido) determina la base de datos de destino según los valores de datos. Por ejemplo, todos los clientes ubicados en la región de América Latina se migran a una base de datos de destino específica que representa a esa región.

Puedes usar ambos tipos de selección al mismo tiempo en una migración de base de datos. Sin importar el tipo de selección que se usó, la base de datos de destino debe tener el esquema correcto para que se almacenen los elementos de datos.

Persistencia de datos en tránsito

Los sistemas de migración de bases de datos o los entornos en los que estos se ejecutan pueden fallar durante una migración, y los datos en tránsito se pueden perder. Cuando ocurren errores, debes reiniciar el sistema de migración de bases de datos y asegurarte de que los datos almacenados en la base de datos de origen se migren de manera coherente y completa a las bases de datos de destino.

Como parte de la recuperación, el sistema de migración de bases de datos debe identificar el último elemento de datos que se migró de forma correcta para determinar dónde comenzar a extraer de las bases de datos de origen. Para reanudar en el punto de falla, el sistema debe mantener un estado interno en el progreso de la migración.

Puedes mantener el estado de varias maneras:

  • Puedes almacenar todos los elementos de datos extraídos dentro del sistema de migración de bases de datos antes de que se realice cualquier modificación de la base de datos y, luego, quitarlos una vez que la versión modificada se haya almacenado de forma correcta en la base de datos de destino. Este método garantiza que el sistema de migración de bases de datos pueda determinar con exactitud lo que se extrae y se almacena.
  • Puedes mantener una lista de referencias a los elementos de datos en tránsito. Una posibilidad es almacenar las claves primarias u otros identificadores únicos de cada elemento de datos junto con un atributo de estado. Después de una falla, este estado es la base para recuperar el sistema de manera coherente.
  • Puedes consultar las bases de datos de origen y de destino después de un error para determinar la diferencia entre los sistemas de base de datos de origen y de destino. El siguiente elemento de datos que se debe extraer se determina en función de la diferencia.

Otros métodos para mantener el estado pueden depender de las bases de datos de origen específicas. Por ejemplo, un sistema de migración de bases de datos puede realizar un seguimiento de las entradas de registro de transacciones que se recuperan a partir la base de datos de origen y las que se insertan en la base de datos de destino. Si se produce un error, la migración se puede reiniciar desde la última entrada que se insertó de forma correcta.

La persistencia de los datos en tránsito también es importante por otras razones que además de los errores o las fallas. Por ejemplo, es posible que no se puedan consultar datos de la base de datos de origen para determinar su estado. Si, por ejemplo, la base de datos de origen contiene una cola, es posible que los mensajes de esa cola se hayan quitado en algún momento.

Otro caso de uso para la persistencia de datos en tránsito es el procesamiento de ventanas de gran tamaño. Durante la modificación de datos, los elementos de datos se pueden transformar de forma independiente. Sin embargo, a veces, la modificación de los datos depende de varios elementos de datos (por ejemplo, numerar los elementos de datos procesados por día, a partir de cero todos los días).

Un caso de uso final para la persistencia de los datos en tránsito es proporcionar la capacidad de repetición de los datos durante la modificación de datos cuando el sistema de base de datos no puede acceder de nuevo a las bases de datos de origen. Por ejemplo, es posible que debas volver a ejecutar las modificaciones de datos con diferentes reglas de modificación y, luego, verificar y comparar los resultados con las modificaciones de datos iniciales. Este método puede ser necesario si necesitas hacer un seguimiento de las inconsistencias en la base de datos de destino debido a una modificación de datos incorrecta.

Verificación de integridad y coherencia

Debes verificar que la migración de la base de datos esté completa y sea coherente. Con esta verificación, se garantiza que cada elemento de datos se migre solo una vez, que los conjuntos de datos en las bases de datos de origen y de destino sean idénticos y que la migración se haya completado.

Según las reglas de modificación de datos, es posible que se extraiga un elemento de datos, pero que no se inserte en una base de datos de destino. Por este motivo, comparar directamente las bases de datos de origen y de destino no es un método sólido para verificar la integridad y la coherencia. Sin embargo, si el sistema de migración de bases de datos realiza un seguimiento de los elementos filtrados, puedes comparar las bases de datos de origen y de destino junto con los elementos filtrados.

Función de replicación del sistema de administración de bases de datos

Un caso de uso especial en una migración homogénea es cuando la base de datos de destino es una copia de la base de datos de origen. En particular, los esquemas en las bases de datos de origen y de destino son los mismos, los valores de los datos son iguales, y cada base de datos de origen es una asignación directa (1:1) a una base de datos de destino.

En este caso, puedes usar la función de replicación integrada que viene con la mayoría de los sistemas de administración de bases de datos para replicar una base de datos en otra.

Existen dos tipos de replicación de datos: lógica y física.

  • Replicación lógica: En el caso de la replicación lógica, los cambios en los objetos de la base de datos se transfieren según sus identificadores de replicación (por lo general, claves primarias). Las ventajas de la replicación lógica son que es flexible, detallada y puedes personalizarla. En algunos casos, la replicación lógica te permite replicar cambios entre diferentes versiones del motor de base de datos. Muchos motores de bases de datos admiten filtros de replicación lógica, en los que puedes definir el conjunto de datos que quieres que se replique. Las principales desventajas son que la replicación lógica podría generar cierta sobrecarga de rendimiento y que la latencia de este método de replicación suele ser más alta que la de la replicación física.

  • Replicación física: Por el contrario, la replicación física funciona a nivel del bloque de disco y ofrece un mejor rendimiento con una latencia de replicación más baja. Para conjuntos de datos grandes, la replicación física puede ser más sencilla y eficiente, en especial en el caso de estructuras de datos no relacionales. Sin embargo, no se puede personalizar y depende en gran medida de la versión del motor de base de datos.

Algunos ejemplos son la replicación de MySQL, la replicación de PostgreSQL (consulta también pdlogical) o la replicación de Microsoft SQL Server.

Sin embargo, si se requiere una modificación de datos o tienes una cardinalidad que no es una asignación directa; se necesitan las funciones de un sistema de migración de bases de datos para abordar ese caso de uso.

Funcionalidad de migración de base de datos personalizada

Entre algunos de los motivos para compilar la función de migración de bases de datos en lugar de usar un sistema de migración de bases de datos o un sistema de administración de bases de datos, se incluyen los siguientes:

  • Necesitas un control total de cada detalle.
  • Deseas volver a usar las capacidades de migración de la base de datos.
  • Quieres reducir los costos o simplificar la huella tecnológica.

Los componentes básicos para compilar la función de migración incluyen los siguientes:

  • Importación y exportación: Si el tiempo de inactividad no es un factor, puedes usar la importación y exportación de bases de datos para migrar datos en migraciones de bases de datos homogéneas. Sin embargo, las operaciones de importación y exportación requieren que desactives la base de datos de origen para evitar actualizaciones antes de exportar los datos. De lo contrario, es posible que los cambios no se registren en la exportación y que la base de datos de destino no sea una copia exacta de la base de datos de origen.
  • Copia de seguridad y restablecimiento: Al igual que en el caso de importación y exportación, las operaciones de copia de seguridad y restablecimiento generan tiempo de inactividad porque necesitas desactivar la base de datos de origen para que la copia de seguridad contenga todos los datos y los cambios más recientes. El tiempo de inactividad continúa hasta que el restablecimiento se completa de forma correcta en la base de datos de destino.
  • Consulta diferencialSi el cambio de esquema de la base de datos es una opción, puedes extender el esquema para que los cambios de la base de datos se puedan consultar en la interfaz de consultas. Se agrega un atributo de marca de tiempo adicional, que indica la hora del último cambio. Se puede agregar una marca de eliminación adicional, que indica si el elemento de datos se borró o no (eliminación lógica). Con estos dos cambios, una aplicación de sondeo que se ejecuta a un intervalo regular puede consultar todos los cambios que se implementaron desde su última ejecución. Los cambios se aplican a la base de datos de destino. En Cambia la captura de datos, se analizan otros métodos.

Estas son solo algunas de las opciones posibles para compilar una migración de base de datos personalizada. Aunque una solución personalizada proporciona la mayor flexibilidad y el mayor control posibles sobre la implementación, también requiere mantenimiento constante para abordar errores, limitaciones de escalabilidad y otros problemas que puedan surgir durante una migración de base de datos.

Consideraciones adicionales para la migración de bases de datos

En las siguientes secciones, se analizan con brevedad los aspectos no funcionales que son importantes en el contexto de la migración de bases de datos. En estos aspectos, se incluyen el manejo de errores, la escalabilidad, la alta disponibilidad y la recuperación ante desastres.

Manejo de errores

Las fallas durante la migración de bases de datos no deben causar la pérdida de datos ni el procesamiento de los cambios de la base de datos en un orden incorrecto. La integridad de los datos debe conservarse sin importar la causa del error (como un error en el sistema, una interrupción de la red, una falla de la VM o una falla en la zona).

Se produce una pérdida de datos cuando un sistema de migración recupera los datos de las bases de datos de origen y no los almacena en las bases de datos de destino debido a algún error. Cuando se pierden datos, las bases de datos de destino no coinciden con las de origen y, por lo tanto, son incoherentes y están incompletas. La función de verificación de integridad y coherencia marca este estado (Verificación de integridad y coherencia).

Escalabilidad

En una migración de base de datos, el tiempo de migración es una métrica importante. En una migración sin tiempo de inactividad (en el sentido de un tiempo de inactividad mínimo), la migración de los datos se produce mientras las bases de datos de origen siguen cambiando. Para migrar en un plazo razonable, la velocidad de transferencia de datos debe ser mucho más rápida que la velocidad de las actualizaciones de los sistemas de bases de datos de origen, en especial, cuando el sistema de base de datos de origen es grande. Cuanto mayor sea la velocidad de transferencia, más rápido se podrá completar la migración de la base de datos.

Cuando los sistemas de bases de datos de origen están inactivos y no se modifican, la migración puede ser más rápida porque no hay cambios que se deban incorporar. En una base de datos homogénea, el tiempo de migración puede ser bastante rápido porque puedes usar las funciones de copia de seguridad y restablecimiento o de importación y exportación, y la transferencia de archivos se escala.

Alta disponibilidad y recuperación ante desastres

En general, las bases de datos de origen y de destino están configuradas para la alta disponibilidad. Una base de datos principal tiene una réplica de lectura correspondiente que se convierte en la base de datos principal cuando se produce una falla.

Cuando una zona falla, las bases de datos de origen o de destino se conmutan por error a una zona diferente para estar disponibles de forma continua. Si se produce una falla zonal durante una migración de bases de datos, el sistema de migración se ve afectado porque varias de las bases de datos de origen o de destino a las que accede se vuelven inaccesibles. El sistema de migración debe volver a conectarse a las bases de datos principales recién promovidas que se ejecutan después de una falla. Una vez que el sistema de migración de bases de datos se vuelve a conectar, debe recuperar la migración para garantizar la integridad y coherencia de los datos en las bases de datos de destino. El sistema de migración debe determinar la última transferencia coherente para establecer desde qué punto se debe reanudar la operación.

Si el sistema de migración de bases de datos falla (por ejemplo, la zona en la que se ejecuta se vuelve inaccesible), debe recuperarse. Un método de recuperación consiste en un reinicio en frío. En este método, el sistema de migración de bases de datos se instala en una zona operativa y se reinicia. El mayor problema que se debe abordar es que el sistema de migración debe poder determinar la última transferencia de datos coherente antes de la falla y continuar desde ese punto a fin de garantizar la integridad y coherencia de los datos en las bases de datos de destino.

Si el sistema de migración de bases de datos está habilitado para la alta disponibilidad, puede conmutar por error y continuar con el procesamiento luego. Si el tiempo de inactividad limitado del sistema de migración de bases de datos es importante, debes seleccionar una base de datos e implementar la alta disponibilidad.

En cuanto a la recuperación de la migración de una base de datos, la recuperación ante desastres es muy similar a la alta disponibilidad. En lugar de volver a conectarse a las bases de datos principales que se acaban de ascender en una zona diferente, el sistema de migración de bases de datos debe volver a conectarse a las bases de datos en una región diferente (una región de conmutación por error). Lo mismo sucede con el sistema de migración de bases de datos. Si la región en la que se ejecuta el sistema de migración de bases de datos se vuelve inaccesible, el sistema de migración de bases de datos debe conmutar por error a una región diferente y continuar a partir de la última transferencia de datos coherente.

Errores

Varios errores pueden generar datos incoherentes en las bases de datos de destino. Algunos de los más comunes que debes evitar son los siguientes:

  • Incumplimiento del orden. Si la escalabilidad del sistema de migración se logra mediante el escalamiento horizontal, varios procesos de transferencia de datos se ejecutan en simultáneo (en paralelo). Los cambios en un sistema de base de datos de origen se ordenan según las transacciones confirmadas. Si los cambios se detectan a partir del registro de transacciones, el orden debe mantenerse durante la migración. La transferencia de datos en paralelo puede cambiar el orden debido a la velocidad variable entre los procesos subyacentes. Es necesario asegurarse de que los datos se inserten en las bases de datos de destino en el mismo orden en que se reciben de las bases de datos de origen.
  • Incumplimiento de la coherencia. Con las consultas diferenciales, las bases de datos de origen tienen atributos de datos adicionales que contienen, por ejemplo, marcas de tiempo de confirmación. Las bases de datos de destino no tendrán marcas de tiempo de confirmación porque estas solo se incluyen para establecer la administración de cambios en las bases de datos de origen. Es importante asegurarse de que las inserciones en las bases de datos de destino sean coherentes con las marcas de tiempo, lo que significa que todos los cambios con la misma marca de tiempo deben estar en la misma transacción de inserción, actualización o upsert. De lo contrario, la base de datos de destino podría tener un estado incoherente (de forma temporal) si se insertan algunos cambios y otros con la misma marca de tiempo no se insertan. Este estado de incoherencia temporal no es importante si no se accede a las bases de datos de destino para el procesamiento. Sin embargo, si se usan para pruebas, la coherencia es primordial. Otro aspecto es la creación de los valores de marca de tiempo en la base de datos de origen y cómo se relacionan con el tiempo de confirmación de la transacción en la que se establecen. Debido a dependencias de confirmación de transacciones, una transacción con una marca de tiempo anterior puede ser visible después de una transacción con una marca de tiempo posterior. Si la consulta diferencial se ejecuta entre las dos transacciones, no verá la transacción con la marca de tiempo anterior, lo que da como resultado una incoherencia en la base de datos de destino.
  • Datos faltantes o duplicados. Cuando se produce una conmutación por error, se requiere una recuperación cuidadosa si algunos datos no están replicados entre la instancia principal y la réplica de conmutación por error. Por ejemplo, cuando una base de datos de origen falla, no todos los datos están replicados en la réplica de conmutación por error. Al mismo tiempo, los datos ya se migraron a la base de datos de destino antes del error. Después de la conmutación por error, la base de datos principal que se acaba de ascender se encuentra atrasada en términos de cambios de datos con respecto a la base de datos de destino (esto se conoce como flashback). Un sistema de migración debe reconocer esta situación y recuperarse de ella, de manera que las bases de datos de destino y de origen vuelvan a ser coherentes.
  • Transacciones locales. Para que las bases de datos de origen y de destino reciban los mismos cambios, un método común consiste en que los clientes escriban en ambas bases de datos en lugar de usar un sistema de migración de datos. Este método presenta varios posibles errores. Un posible error consiste en que dos operaciones de escritura de la base de datos sean dos transacciones separadas; es posible que se genere una falla después de que termine la primera y antes de que termine la segunda. Esta situación genera datos incoherentes cuya situación debes revertir. Además, hay varios clientes en general y no están coordinados. Los clientes no conocen el orden de confirmación de las transacciones de la base de datos de origen y, por lo tanto, no pueden escribir en las bases de datos de destino de modo que se implemente ese orden de transacciones. Los clientes pueden cambiar el orden, lo que puede generar incoherencia de datos. A menos que todo el acceso pase por clientes coordinados y que todos los clientes garanticen el orden de las transacciones de destino, este método puede generar un estado de incoherencia con la base de datos de destino.

En general, hay otros errores que se deben tener en cuenta. La mejor manera de encontrar problemas que puedan generar casos de incoherencia de datos es realizar un análisis completo de las fallas que itere todas las situaciones de fallas posibles. Si la simultaneidad se implementa en el sistema de migración de bases de datos, se deben examinar todos los posibles órdenes de ejecución de procesos de migración de datos para garantizar que se conserve la coherencia de datos. Si se implementa la alta disponibilidad o la recuperación ante desastres (o ambas), se deben examinar todas las combinaciones de fallas posibles.

¿Qué sigue?