En este documento se explica cómo configurar y ejecutar el proceso de migración de bases de datos, incluidos los casos de error. Este documento es la segunda parte de dos. En la parte 1 se presentan los conceptos, los principios y la terminología de la migración de bases de datos con un tiempo de inactividad casi nulo para los arquitectos de la nube que necesiten migrar bases de datos a Google Clouddesde entornos on-premise u otras nubes.
Configuración de la migración de bases de datos
En esta sección se describen las distintas fases de una migración de base de datos. Primero, configura la migración. Después de completar la migración y cambiar los clientes a las bases de datos de destino, puedes eliminar las bases de datos de origen o, si es necesario, implementar un plan de recuperación debido a problemas con la migración después del cambio. Una alternativa ayuda a asegurar la continuidad del negocio.
Durante la migración, debes prestar especial atención a los cambios de esquema o de datos que se puedan introducir. Para obtener más información sobre el impacto que pueden tener estos cambios, consulta la sección Cambios dinámicos durante la migración más adelante en este documento.
Especificación del esquema de destino
En cada sistema de base de datos de destino, debe definir y crear su esquema. En el caso de las migraciones de bases de datos homogéneas, puedes crear esta especificación más rápidamente exportando el esquema de la base de datos de origen a la de destino, lo que te permitirá crear el esquema de la base de datos de destino.
El nombre que elijas para tu esquema es importante. Una opción es hacer coincidir los nombres de los esquemas de origen y de destino. Sin embargo, aunque esto simplifica el cambio de clientes, este enfoque podría confundir a los usuarios si las herramientas se conectan a los esquemas de la base de datos de origen y de destino simultáneamente (por ejemplo, para comparar datos). Si abstrae el nombre del esquema mediante un archivo de configuración, asignar nombres diferentes a los esquemas de la base de datos de destino y de la de origen facilita la diferenciación de los esquemas.
En las migraciones de bases de datos heterogéneas, debe crear cada esquema de base de datos de destino. Este proceso de ingeniería puede requerir varias iteraciones. Antes de implementar la migración, es posible que tengas que cambiar los esquemas para adaptarlos al proceso de migración y a las modificaciones de datos.
Como es probable que crees bases de datos de destino varias veces al probar y ejecutar la migración, el proceso de creación del esquema debe poder repetirse (lo ideal es que se realice mediante secuencias de comandos de instalación). Puedes usar un sistema de gestión de código para controlar la versión de las secuencias de comandos, asegurar la coherencia y acceder al historial de cambios de las secuencias de comandos.
Semántica de migración y ejecución de consultas
Finalmente, tendrás que cambiar el acceso de los clientes de los sistemas de bases de datos de origen a los sistemas de bases de datos de destino. En las integraciones de bases de datos homogéneas, las consultas pueden permanecer sin cambios si los esquemas no se modifican. Aunque los clientes se deben probar en los sistemas de bases de datos de destino, no es necesario modificarlos debido a las consultas.
En el caso de las migraciones de bases de datos heterogéneas en general, debe modificar las consultas, ya que los esquemas de las bases de datos de origen y de destino son diferentes. La diferencia puede deberse a una discrepancia en el tipo de datos entre las bases de datos de origen y de destino. Además, es posible que no todas las funciones del lenguaje de consulta disponibles en los sistemas de bases de datos de origen estén disponibles en los sistemas de bases de datos de destino, o viceversa. En casos extremos, puede que tengas que convertir una consulta de un sistema de base de datos de origen en varias consultas en el sistema de destino. En el caso contrario, si la base de datos de destino tiene más funciones de lenguaje de consulta que la de origen, es posible que tengas que combinar varias consultas de la base de datos de origen en una sola consulta en la base de datos de destino correspondiente.
La semántica de las consultas también puede variar. Por ejemplo, algunos sistemas de bases de datos materializan una actualización en una transacción inmediatamente dentro de esa transacción, por lo que, cuando se lee el mismo elemento de datos, se recupera el valor actualizado. Otros sistemas no materializan una actualización inmediatamente y esperan hasta que se confirme la transacción. Si la lógica del sistema de base de datos de origen se basa en que la escritura se materialice, la misma lógica en la base de datos de destino puede provocar que los datos sean incorrectos o incluso que se produzcan errores.
Si debes migrar consultas, tienes que probar todas las funciones para asegurarte de que el comportamiento de los clientes sea el mismo antes y después de la migración. También puede hacer pruebas a nivel de datos, pero estas pruebas no sustituyen a las que se realizan a nivel de cliente. Los clientes ejecutan consultas desde el punto de vista de la lógica empresarial y solo se pueden probar a nivel de lógica empresarial.
Procesos de migración
En las migraciones de bases de datos heterogéneas, los procesos de migración especifican cómo se modifican los datos extraídos de los sistemas de bases de datos de origen y cómo se insertan en las bases de datos de destino. Las modificaciones de datos, como las que se describen en la sección Cambios en los datos de este documento, se definen y se ejecutan mientras se extraen elementos de datos de las bases de datos de origen y se transfieren a las bases de datos de destino.
En las migraciones de bases de datos homogéneas, cuando los esquemas de las bases de datos de origen y de destino son equivalentes, no es necesario modificar los datos. Los datos se insertan en las bases de datos de destino tal como se extrajeron de las bases de datos de origen.
En función del sistema de migración de bases de datos, es posible que se requieran varias configuraciones. Por ejemplo, debe especificar si los datos que se modifican y transfieren deben almacenarse de forma intermitente en el sistema de migración de bases de datos. Almacenar los datos puede ralentizar el proceso de migración en general, pero acelera significativamente la recuperación si se produce un fallo. Es posible que tengas que especificar el tipo de verificación. Por ejemplo, algunos sistemas de migración de bases de datos consultan los sistemas de origen y de destino para establecer la equivalencia del conjunto de datos migrado hasta el momento de la consulta. Para gestionar los errores, debe especificar el comportamiento de recuperación tras fallos. De nuevo, este requisito depende del sistema de migración de bases de datos que se utilice.
No hace falta decir que debes probar la migración de datos a fondo y repetidamente. Lo ideal es que pruebes la migración para asegurarte de que se migran todos los elementos de datos conocidos, de que no se producen errores de modificación de datos, de que el rendimiento y el procesamiento son suficientes y de que se puede completar la migración en el tiempo previsto.
Procesos alternativos
Durante una migración de bases de datos, las bases de datos de origen siguen operativas (a menos que la migración implique un tiempo de inactividad planificado). Si la migración de la base de datos falla en cualquier momento, puedes (en el peor de los casos) abortar la migración y restablecer la base de datos de destino a su estado inicial. Una vez que hayas resuelto los errores, puedes reiniciar la migración de la base de datos. El error y la resolución no afectan a los sistemas de bases de datos de origen operativos.
Si se producen errores después de completar la migración de la base de datos y los clientes se cambian a las bases de datos de destino, el proceso de resolución de errores puede afectar a los clientes de forma que no puedan operar correctamente. En el mejor de los casos, el fallo se resuelve rápidamente y el tiempo de inactividad para los clientes es breve. En el peor de los casos, el fallo no se resuelve o la resolución lleva mucho tiempo y debes volver a cambiar los clientes a las bases de datos de origen.
Para volver a cambiar los clientes a las bases de datos de origen, debes migrar todas las modificaciones de datos de las bases de datos de destino a las bases de datos de origen. Puedes configurar y ejecutar este proceso como una migración de base de datos completa e independiente. Sin embargo, como los clientes no pueden operar en las bases de datos de destino en este punto, se producirá un tiempo de inactividad considerable.
Para evitar que los clientes sufran tiempos de inactividad en este caso, debes iniciar los procesos de migración inmediatamente después de que se complete la migración de la base de datos original. Todos los cambios que se aplican a los sistemas de bases de datos de destino se aplican inmediatamente a los sistemas de bases de datos de origen. Si sigues este enfoque, te asegurarás de que los sistemas de bases de datos de origen y de destino estén sincronizados en todo momento.
Preparar una alternativa de las bases de datos de destino a las de origen requiere un esfuerzo considerable. Es fundamental decidir si se van a implementar y probar procesos de respaldo o si se van a asumir las consecuencias de no hacerlo, es decir, un tiempo de inactividad considerable.
Ejecución de la migración de bases de datos
Para llevar a cabo una migración de bases de datos, hay que seguir cinco fases distintas, que se describen en esta sección. La sexta fase es una alternativa, pero se trata de un caso extremo y se considera una excepción a la ejecución normal de la migración de la base de datos.
El proceso que se describe en esta sección es una migración de bases de datos heterogénea con un tiempo de inactividad casi nulo. Si puedes permitirte un tiempo de inactividad considerable, puedes combinar las tres primeras fases (carga inicial, migración continua y drenaje) en una sola fase mediante la copia de seguridad y restauración o la exportación e importación.
La migración de bases de datos homogénea es un caso especial. Con este tipo de migración, puedes usar la función de replicación del sistema de gestión de bases de datos (en los sistemas que la admiten) para migrar los datos mientras los sistemas de bases de datos de origen siguen operativos.
Las fases que se describen aquí definen un enfoque que puede que tengas que modificar en función de los requisitos de tu proceso de migración de bases de datos.
Fase 1: Carga inicial
El punto de partida es migrar todos los datos especificados de todas las bases de datos de origen. Al inicio de la migración de datos, las bases de datos de origen tienen un estado específico, y ese estado cambia durante la migración.
Un consejo para iniciar una migración mientras se producen cambios simultáneamente es anotar la hora del sistema de la base de datos justo antes de extraer el primer elemento de datos. Con esta marca de tiempo, puede obtener todos los cambios de la base de datos a partir de ese momento en el registro de transacciones. Además, la carga inicial debe leer un estado de la base de datos coherente en todos los datos. Es posible que necesites un bloqueo de corta duración en la base de datos para evitar que se lea un conjunto de datos incoherente.
Esta fase consta de lo siguiente:
- Anotar la hora del sistema de la base de datos justo antes de que empiece la migración de la base de datos.
- Ejecutar un proceso de migración de carga inicial que consulte el conjunto de datos (ya sea completo o parcial) de las bases de datos de origen que se deban migrar y migrar el conjunto de datos. En un modelo de base de datos relacional, los procesos de migración de carga inicial ejecutan consultas como
SELECT *o consultas con selección, proyección o ambas. El proceso de migración modifica los datos según lo especificado en el proceso.
Mientras se ejecutan los procesos de migración de carga inicial, los clientes suelen hacer cambios en las bases de datos de origen. Como registras la hora del sistema de la base de datos al principio, puedes obtener esos cambios del registro de transacciones más adelante.
El resultado de la fase de carga inicial es la migración completa del conjunto de datos inicial de los sistemas de bases de datos de origen a los de destino. Sin embargo, las bases de datos de origen y de destino aún no están sincronizadas porque es probable que los clientes hayan modificado las bases de datos de origen durante la migración. En la fase 2, se capturan y se migran esos cambios.
Fase 2: Continuar con la migración
Continuar con la migración tiene dos objetivos. En primer lugar, lee los cambios que se han producido en las bases de datos de origen después de que se haya iniciado la carga inicial. En segundo lugar, captura y transfiere esos cambios a las bases de datos de destino.
Esta fase consta de lo siguiente:
- Iniciar los procesos de migración continuos desde el sistema de base de datos hora registrada en la fase 1. La migración lee el registro de transacciones desde ese momento y aplica todos los cambios al sistema de base de datos de destino.
- Ejecutar cualquier modificación de datos. El proceso de migración realiza este paso según lo especifiques.
Los cambios que se registran después de la hora del sistema de la base de datos a veces se transfieren durante la carga inicial. Por lo tanto, es posible que esos cambios se apliquen una segunda vez durante la migración continua. Debes definir tus procesos de migración para asegurarte de que los cambios no se apliquen dos veces. Por ejemplo, puedes usar identificadores. Supongamos que se transfiere un elemento de datos modificado durante la carga inicial y que la inserción se registra en el registro de transacciones. Al aplicar un identificador al elemento de datos, el sistema de migración puede determinar a partir del registro de transacciones que no es necesario insertar otro elemento porque el elemento de datos ya existe.
Como resultado de la fase de migración continua, las bases de datos de destino están totalmente sincronizadas o casi totalmente sincronizadas con las bases de datos de origen. Si no se migra un cambio en un sistema de base de datos de origen, la base de datos estará casi sincronizada.
En función de cómo configures tu sistema de migración de bases de datos, las discrepancias pueden ser pequeñas o grandes. Por ejemplo, para aumentar la eficiencia, no todos los cambios se deben migrar inmediatamente. De lo contrario, se puede crear una carga pesada en la fuente si los cambios en la fuente aumentan de forma repentina. Por lo general, los cambios se recogen y se migran en lotes como operaciones en bloque. Con lotes más pequeños, se producen menos discrepancias entre la fuente y el destino, pero la fuente puede incurrir en una carga mayor si se realizan cambios con frecuencia.
Si el tamaño del lote se configura de forma dinámica, es mejor sincronizar lotes más grandes al principio de la fase de migración continua y, a continuación, sincronizar lotes de un tamaño que se vaya reduciendo gradualmente cuando las bases de datos estén casi al día. De esta forma, el proceso de sincronización es más eficiente y se reduce la discrepancia entre las bases de datos de origen y de destino más adelante.
Fase 3: Drenaje
Para preparar el cambio de clientes de las bases de datos de origen a las de destino, debes asegurarte de que las bases de datos de origen y la de destino estén totalmente sincronizadas. El vaciado es el proceso de migración de los cambios restantes de las bases de datos de origen a las de destino.
Esta fase consta de lo siguiente:
- Poner en reposo los sistemas de bases de datos de origen. Esto significa que no se pueden modificar los datos en la base de datos de origen y que el registro de transacciones no recibe entradas de modificación adicionales.
- Esperando a que todos los cambios se migren a las bases de datos de destino. Este proceso es el que realmente agota los cambios.
- Una vez que se haya completado el drenaje, se hará una copia de seguridad de las bases de datos de destino para tener un punto de partida definido para futuras copias de seguridad incrementales.
El resultado de la fase de purga es que los sistemas de bases de datos de origen y de destino se sincronizan, y no se producen modificaciones en los datos.
Para asegurarse de que el vaciado se ha completado, se puede escribir un elemento de datos de "última inserción" en una base de datos de origen. Una vez que aparece ese elemento de datos de "última inserción" en la base de datos de destino correspondiente, se completa la fase de purga.
Fase 4: Cambio
Una vez completada la fase de drenaje, puedes cambiar los clientes de las bases de datos de origen a las de destino. Te recomendamos que sigas estas prácticas recomendadas:
- Antes de habilitar el acceso a la base de datos de producción, prueba las funciones básicas para asegurarte de que los clientes funcionan correctamente y se comportan como se espera. El número de casos de prueba determinará el tiempo de inactividad real de tu base de datos de producción.
- Crea una copia de seguridad de las bases de datos de destino antes de habilitar el acceso de los clientes. Esta práctica recomendada asegura que se pueda recuperar el estado inicial de las bases de datos de destino.
Al final del cambio, los clientes estarán operativos y empezarán a acceder a las bases de datos de producción (lo que en este documento se ha denominado bases de datos de destino hasta ahora).
Fase 5: Eliminación de la base de datos de origen
Una vez que hayas completado el cambio a las bases de datos de producción, puedes eliminar las bases de datos de origen. Te recomendamos que hagas una copia de seguridad final de cada base de datos de origen para tener un estado final definido al que puedas acceder. Las normativas de datos también pueden requerir copias de seguridad finales por motivos de cumplimiento.
Fase 6: Fallback
Implementar una alternativa, sobre todo en el caso de los clientes de bases de datos de alta importancia, puede ser una buena medida de protección contra problemas con la migración. Una alternativa es como una migración, pero al revés. Es decir, con una alternativa, se configura una migración de las bases de datos de destino a las de origen. En las migraciones de bases de datos heterogéneas, la restauración es más compleja. Por eso, te recomendamos que hagas el cambio solo después de probar a fondo que el proceso de migración de la base de datos y las aplicaciones conectadas a la base de datos de destino cumplen los acuerdos de nivel de servicio (SLAs).
Después de vaciar las bases de datos de origen y crear copias de seguridad de todas las bases de datos, puedes habilitar procesos de migración que identifiquen los cambios en las bases de datos de destino y los migren a las bases de datos de origen antes del cambio.
La creación de estos procesos de migración asegura que, después de que los clientes hagan cambios en las bases de datos de destino, las bases de datos de origen se sincronicen y su estado de datos se mantenga actualizado. Es posible que se necesite una alternativa días o semanas después del cambio. Por ejemplo, es posible que los clientes accedan a una función por primera vez y se les bloquee debido a una función que no funciona y que no se puede corregir rápidamente. En este caso, los clientes pueden volver a acceder a las bases de datos de origen. Antes de volver a cambiar los clientes, todos los cambios realizados en las bases de datos de destino deben transferirse a las bases de datos de origen.
En este enfoque, hay algunas circunstancias que requieren una atención especial:
- Debes diseñar los esquemas de destino de forma que sea posible realizar una migración inversa (de las bases de datos de destino a las de origen). Por ejemplo, si el proceso de migración inicial (de la fuente al destino) tiene combinaciones o agregaciones, una migración inversa no es trivial o incluso es imposible. En ese caso, los datos individuales también deben estar disponibles en las bases de datos de destino.
- Puede surgir un problema en el que las bases de datos de origen tengan registros de transacciones, pero las de destino no proporcionen una función no funcional de este tipo. En este caso, una migración inversa (del destino al origen) debe basarse en consultas diferenciales. Esa configuración debe diseñarse y prepararse en los esquemas de la base de datos de destino.
- Los clientes que originalmente operaban en las bases de datos de origen deben seguir estando disponibles y operativos para que se puedan activar en caso de fallo. Cualquier cambio funcional que se haga en los clientes que acceden a las bases de datos de destino también se debe hacer en los clientes que acceden a la base de datos de origen para asegurar la equivalencia funcional.
Aunque el fallback es el último recurso, es fundamental implementarlo y debe tratarse como una migración completa de la base de datos, lo que incluye las pruebas.
Cambios dinámicos durante la migración
En general, las bases de datos son sistemas dinámicos porque el esquema y los valores de los datos pueden cambiar. Los esquemas de bases de datos pueden cambiar en función de factores como los requisitos empresariales, y los valores de los datos pueden cambiar junto con los cambios en los esquemas o de forma independiente. Los cambios en los valores de los datos pueden producirse de forma dinámica en cualquier momento con los cambios correspondientes en la implementación de una aplicación. En las siguientes secciones se analizan algunos de los posibles cambios y sus implicaciones en una migración de base de datos.
Cambios en el esquema
Las bases de datos se pueden clasificar en sistemas que requieren un esquema predefinido o que no tienen esquema. Por lo general, los sistemas que requieren un esquema predefinido admiten operaciones de cambio de esquema, como añadir atributos o columnas en un sistema relacional.
En estos sistemas, los cambios se controlan mediante un proceso de gestión del cambio. Un proceso de gestión de cambios permite realizar cambios de forma controlada. Cualquier operación que dependa del esquema, como las consultas o los procesos de migración de datos, se cambia simultáneamente para asegurar que el cambio sea coherente en general.
Los sistemas de bases de datos que no requieren un esquema predefinido se pueden cambiar en cualquier momento. Un cambio de esquema no solo lo puede hacer un usuario autorizado, sino que, en algunos casos, se puede hacer de forma programática. En estos casos, el cambio de esquema puede producirse en cualquier momento. Es posible que las operaciones que dependen del esquema fallen, como las consultas o los procesos de migración de datos. Para evitar cambios de esquema incontrolados en estos sistemas de bases de datos, debes implementar un proceso de gestión de cambios como convención y regla aceptada, en lugar de mediante la aplicación del sistema.
Cambios en los datos
En general, los esquemas controlan los posibles valores de datos de los distintos atributos de datos. Los sistemas sin esquema no tienen restricciones en los valores de los datos.
En ambos casos, pueden aparecer valores de datos que no se hayan almacenado previamente. Por ejemplo, los tipos de enumeración se suelen implementar como un conjunto de cadenas en los sistemas de bases de datos. A nivel de lenguaje de programación, estos tipos se pueden implementar en los clientes como tipos de enumeración verdaderos, pero no necesariamente. Es posible que un cliente almacene lo que considera un valor de enumeración válido que otros clientes no consideran válido. Además, un proceso de migración de datos puede basar su funcionalidad en valores de enumeración. Si aparecen valores nuevos, es posible que el proceso de migración de datos falle.
Otro ejemplo se encuentra en el almacenamiento de estructuras JSON. En muchos casos, las estructuras JSON se almacenan en una cadena de tipo de datos. Sin embargo, se interpretan como valores JSON al acceder a ellas. Si cambia la estructura JSON, el sistema de base de datos no lo detectará. Los procesos de migración de datos que interpreten una cadena como un valor JSON podrían fallar.
Cambios en el proceso de migración
Gestionar los cambios durante una migración de base de datos en curso es difícil y complejo, y puede provocar errores en la migración de datos o incoherencias en los datos. Lo ideal es que los cambios necesarios se retrasen hasta el final de la fase de purga, momento en el que se sincronizan los sistemas de bases de datos de origen y de destino. Los cambios que se hagan en este punto se limitarán a las bases de datos de destino y a sus clientes (a menos que también se implemente una alternativa).
Si necesitas cambiar el proceso de migración durante una migración de datos, te recomendamos que hagas los cambios mínimos posibles y que hagas varios cambios pequeños en lugar de uno más complejo. Además, puede probar primero esos cambios usando instancias de prueba de las bases de datos de origen y de destino. Lo ideal es que cargues la fuente de prueba con datos de producción que luego migres al destino de prueba. Con este método, puedes verificar los cambios propuestos sin que afecten a la migración de producción en curso. Después de probar y verificar los cambios, puedes aplicarlos al sistema de producción.
Para poder hacer cambios durante una migración de datos en curso, debes poder detener el sistema de migración de datos y reiniciarlo, posiblemente con procesos de migración de datos modificados. En ese caso, no tiene que empezar desde el principio con una fase de carga de datos inicial. Si el sistema de migración de datos admite una función de prueba de migración, también puedes usarla.
Te recomendamos que no cambies el esquema, los valores de datos ni los procesos de migración de datos durante una migración de datos. Si tienes que hacer cambios, te recomendamos que reinicies la migración de datos desde el principio para asegurarte de que tienes un estado inicial definido. En cualquier caso, es fundamental que hagas pruebas con datos de producción y que crees copias de seguridad de tus bases de datos antes de aplicar los cambios para que, si es necesario, puedas restablecer el sistema en general a un estado coherente.
Mitigación de errores de migración
Pueden surgir problemas inesperados durante una migración de base de datos. A continuación, se destacan algunas áreas que pueden requerir una planificación previa:
- Rendimiento insuficiente. Un sistema de migración puede no tener suficiente rendimiento a pesar de las pruebas de carga. Este problema puede deberse a muchos motivos, como un aumento imprevisto de la frecuencia de los cambios en la base de datos de origen o la limitación de la red. Puedes prepararte para este caso preparando recursos adicionales para escalar verticalmente o horizontalmente todos los componentes implicados.
- Inestabilidad de la base de datos. Las bases de datos de origen o de destino pueden mostrar inestabilidad, lo que puede ralentizar los procesos de migración de datos o impedir el acceso de forma intermitente. Es posible que los procesos de migración de datos tengan que recuperarse con frecuencia. En este caso, un cambio intencional a alta disponibilidad o recuperación ante desastres podría solucionar el problema. Un cambio cambia el entorno no funcional (máquinas y almacenamiento) y puede ayudar a mitigar el problema. En este caso, debes probar los procesos de cambio y recuperación de la migración de la base de datos para asegurarte de que el cambio no provoque incoherencias en los datos de las bases de datos de destino.
- Agotamiento del tamaño del archivo de registro de transacciones. En algunos casos, los registros de transacciones se almacenan en archivos que tienen un límite superior. Es posible que se alcance este límite superior y que la migración de la base de datos falle. Es importante saber qué partes de un sistema de base de datos se pueden reconfigurar dinámicamente para abordar las limitaciones de recursos a medida que surjan. Si no se pueden configurar dinámicamente ciertos aspectos, el tamaño inicial debe determinarse con cuidado.
Cuanto más realistas y completas sean las pruebas iniciales, más probabilidades habrá de que encuentres posibles problemas que solucionar con antelación.
Siguientes pasos
- Consulta los siguientes recursos sobre la migración de bases de datos:
- Consulta Migración de bases de datos para ver más guías de migración de bases de datos.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.