En este documento, se analiza la configuración y la ejecución del proceso de migración de la base de datos, incluidas las situaciones de errores. Este documento es la parte 2 de una serie de dos partes. En la parte 1, se presentan conceptos, principios y terminología de la migración de bases de datos con tiempo de inactividad casi nulo para los arquitectos que necesitan migrar bases de datos a Google Cloud de entornos locales o de otras nubes.
Configuración de la migración de bases de datos
En esta sección, se describen las diversas fases de una migración de bases de datos. Primero, configuras la migración. Luego de completar la migración y cambiar los clientes a las bases de datos de destino, quita las bases de datos de origen o, si es necesario, implementa un plan de resguardo debido a problemas con la migración después del cambio. Un resguardo ayuda a garantizar la continuidad de la empresa.
Durante la migración, debes prestar atención especial a cualquier cambio de esquema o de datos que pueda producirse. Para obtener más información sobre el impacto que pueden tener estos cambios, consulta Cambios dinámicos durante la migración más adelante en este documento.
Especificación del esquema de destino
Para cada sistema de base de datos de destino, debes definir y crear su esquema. Para las migraciones de bases de datos homogéneas, puedes crear esta especificación más rápido si exportas el esquema de la base de datos de origen a la base de datos de destino, lo que crea el esquema de las bases de datos de destino.
La forma en que nombras tu esquema es importante. Una opción es hacer coincidir los nombres del esquema 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 las bases de datos de origen y de destino de forma simultánea, por ejemplo, para comparar datos. Si abstraes el nombre del esquema mediante un archivo de configuración, asignar nombres diferentes a los esquemas de la base de datos de destino facilita la diferenciación de los esquemas.
En las migraciones de bases de datos heterogéneas, debes crear cada esquema de la base de datos de destino. Este proceso de ingeniería puede llevar varias iteraciones. Antes de que puedas implementar la migración, es posible que debas cambiar los esquemas un poco más para ajustar tu proceso de migración y cualquier modificación de los datos.
Debido a que es probable que crees bases de datos de destino varias veces cuando pruebes y ejecutes la migración, el proceso de creación del esquema debe ser repetible (lo ideal es hacerlo mediante secuencias de comandos de instalación). Puedes usar un sistema de administración de código para controlar la versión de las secuencias de comandos, garantizar la coherencia y acceder al historial de cambios de las secuencias de comandos.
Semántica de migración y ejecución de consultas
Con el tiempo, debes realizar un cambio para que el cliente deje de acceder a los sistemas de la base de datos de origen y acceda a los de destino. En integraciones de bases de datos homogéneas, las consultas pueden permanecer sin cambios si los esquemas no se modifican. Si bien los clientes deben probarse en los sistemas de la base de datos de destino, los clientes no tienen que modificarse debido a las consultas.
En el caso de las migraciones de bases de datos homogéneas en general, debes modificar las consultas porque los esquemas entre las bases de datos de origen y destino son diferentes. La diferencia podría ser una discrepancia de tipos de datos entre las bases de datos de origen y de destino. Además, no todas las funciones del lenguaje de consulta disponibles en los sistemas de la base de datos de origen pueden estar disponibles en los sistemas de la base de datos de destino, o viceversa. En casos extremos, es posible que debas convertir una consulta de un sistema de la base de datos de origen en varias consultas en el sistema de destino. En una situación inversa, en la que tienes más funciones de lenguaje de consulta disponibles en la base de datos de destino que en la base de datos de origen, es posible que debas 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 dentro de una transacción de inmediato, por lo que se recupera el valor actualizado cuando se lee el mismo elemento de datos. Otros sistemas no materializan una actualización de inmediato y esperan hasta que se confirme la transacción. Si la lógica en el sistema de la base de datos de origen depende de que se materialice la escritura, la misma lógica en la base de datos de destino puede generar datos incorrectos o incluso fallas.
Si debes migrar consultas, debes 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 puedes realizar pruebas a nivel de los datos, pero estas no reemplazan a las pruebas a nivel del cliente. Los clientes ejecutan consultas desde el punto de vista de la lógica empresarial y solo se pueden probar a nivel de la lógica empresarial.
Procesos de migración
Para las migraciones de bases de datos heterogéneas, los procesos de migración especifican cómo se modifican y se insertan los datos extraídos de los sistemas de la base de datos de origen en la de destino. Las modificaciones de datos, como las que se analizan en Cambios de datos en este documento, se definen y se ejecutan mientras los elementos de datos se extraen de las bases de datos de origen y se transfieren a las 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 como se extrajeron de las bases de datos de origen.
Según el sistema de migración de la base de datos, es posible que se requieran varios parámetros de configuración. Por ejemplo, debes especificar si los datos que se modifican y se transfieren deben almacenarse de forma intermitente en el sistema de migración de la base de datos. El almacenamiento de los datos puede ralentizar el proceso de migración general, pero acelerar bastante la recuperación en caso de que ocurra una falla. Es posible que debas 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 punto de la consulta. El control de errores requiere que especifiques el comportamiento de recuperación ante fallas. Este requisito también dependerá del sistema de migración de bases de datos en uso.
Es importante que pruebes la migración de datos de forma exhaustiva y repetida. Lo ideal es que la migración se pruebe para garantizar que se migren todos los elementos de datos conocidos, que no se produzcan errores de modificación de datos, que el rendimiento y la capacidad de procesamiento sean suficientes y que se pueda cumplir el tiempo de migración.
Procesos de resguardo
Durante una migración de bases de datos, las bases de datos de origen permanecen en funcionamiento (a menos que la migración implique tiempo de inactividad planificado). Si la migración de tu base de datos falla en algún momento, puedes (en el peor de los casos) anular la migración y restablecer la base de datos de destino a su estado inicial. Después de resolver los errores, puedes reiniciar la migración. La falla y la resolución no afectan a los sistemas operativos de las bases de datos de origen.
Si ocurren fallas después de que se completa la migración de la base de datos y se cambian los clientes a las bases de datos de destino, el proceso de falla y resolución puede afectar a los clientes de modo que no puedan funcionar de manera correcta. En el mejor de los casos, la falla se resuelve con rapidez y el tiempo de inactividad para los clientes es corto. En el peor de los casos, la falla 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 de origen. Puedes configurar y ejecutar este proceso como una migración de base de datos independiente y completa. Sin embargo, debido a que los clientes no funcionan en las bases de datos de destino en este punto, se generará un tiempo de inactividad significativo.
Para evitar el tiempo de inactividad del cliente en esta situación, debes iniciar los procesos de migración de inmediato una vez de que se complete la migración de la base de datos original. Cada cambio que se aplica a los sistemas de la base de datos de destino se aplica de inmediato a los sistemas de la base de datos de origen. Mediante este enfoque, se garantiza que los sistemas de la base de datos de destino y de origen se mantengan sincronizados en todo momento.
Preparar un resguardo de las bases de datos de destino a las bases de datos de origen requiere un esfuerzo significativo. Es fundamental decidir entre implementar y probar procesos de resguardo, o comprender las consecuencias de no hacerlo, es decir, un tiempo de inactividad significativo.
Ejecución de la migración de bases de datos
Ejecutar una migración de bases de datos implica cinco fases distintas, que se analizan en esta sección. Una sexta fase comprende un resguardo, pero es un caso extremo y se considera una excepción a la ejecución de una migración de bases de datos normal.
El proceso que se analiza en esta sección es una migración de bases de datos heterogéneas con un tiempo de inactividad casi nulo. Si puedes incurrir en un tiempo de inactividad significativo, puedes combinar las tres primeras fases (carga inicial, migración continua y desvío) en una fase mediante el enfoque de copia de seguridad y restablecimiento, o de importación y exportación.
Una migración de bases de datos homogéneas presenta un caso especial. Con este tipo de migración, puedes usar la funcionalidad de replicación del sistema de administración de bases de datos (para los sistemas compatibles) que migra los datos mientras los sistemas de las bases de datos de origen permanecen operativos.
Las fases analizadas aquí describen un enfoque que quizás debas modificar según 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 para migrar de todas las bases de datos de origen. Al comienzo de la migración de datos, las bases de datos de origen tienen un estado específico, que cambia durante la migración.
Una sugerencia para iniciar una migración mientras se producen cambios de forma simultánea es anotar la hora del sistema de la base de datos justo antes de que se extraiga el primer elemento de datos. Con esta marca de tiempo, puedes obtener todos los cambios de la base de datos del registro de transacciones a partir de ese momento. Además, la carga inicial debe leer un estado de 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 la lectura de un conjunto de datos incoherente.
Esta fase consta de lo siguiente:
- Tomar nota de la hora del sistema de la base de datos justo antes de que comience la migración
- Ejecutar un proceso de migración de carga inicial que consulta el conjunto de datos (ya sea completo o parcial) desde las bases de datos de origen que se migrarán y migrar el conjunto de datos. En un modelo de base de datos relacional, los procesos de migración de carga iniciales ejecutan consultas como
SELECT *, o consultas con selección, proyección o ambas opciones. El proceso de migración realiza la modificación de los datos como se especifica en el proceso.
Mientras se ejecutan los procesos de migración de carga inicial, los clientes suelen realizar cambios en las bases de datos de origen. Debido a que registras la hora del sistema de la base de datos al principio, podrás 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 desde los sistemas de las bases de datos de origen hacia los sistemas de las bases de datos 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. La fase 2 implica capturar y migrar esos cambios.
Fase 2: Continuación de la migración
La continuación de la migración tiene dos fines. Primero, lee los cambios que se produjeron en las bases de datos de origen después del inicio de 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 continuación de la migración desde la hora del sistema de la base de datos registrada en la fase 1. La migración lee el registro de transacciones desde esa hora y aplica cada cambio al sistema de la base de datos de destino.
- Ejecutar todas las modificaciones de datos. El proceso de migración realiza este paso como lo especificas.
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 por segunda vez durante la continuación de la migración. Debes definir tus procesos de migración para asegurarte de que los cambios no se apliquen dos veces, por ejemplo, mediante identificadores. Supongamos que un elemento de datos modificado se transfiere durante la carga inicial y esa inserción se registra en el registro de transacciones. Cuando aplicas un identificador al elemento de datos, el sistema de migración puede determinar a partir del registro de transacciones que no se necesita otra inserción porque el elemento de datos ya existe.
El resultado de la fase de continuación de la migración es que las bases de datos de destino están sincronizadas en su totalidad o casi en ella con las bases de datos de origen. Cuando un cambio en un sistema de la base de datos de origen no se migra, tienes una base de datos casi sincronizada.
Según cómo configures el 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 de inmediato; de lo contrario, puedes generar una gran carga en el origen si aumentan los cambios abruptos. En general, los cambios se recopilan y se migran en lotes como operaciones masivas. Con lotes más pequeños, se producen menos discrepancias entre el origen y el destino, pero el origen puede generar una carga mayor si se realizan cambios con frecuencia.
Si el tamaño del lote se configura de forma dinámica, lo mejor es sincronizar los lotes más grandes al inicio en la fase de continuación de la migración y, luego, sincronizar lotes cuyo tamaño se reduce de forma gradual cuando las bases de datos estén casi listas. Este enfoque hace que el proceso de actualización sea más eficiente y reduce la discrepancia entre las bases de datos de origen y de destino más adelante.
Fase 3: Desvío
A fin de prepararte para cambiar los clientes de las bases de datos de origen a las de destino, debes asegurarte de que las bases de datos estén completamente sincronizadas. El desvío es el proceso de migración de los cambios restantes de las bases de datos de origen a las bases de datos de destino.
Esta fase consta de lo siguiente:
- Dejar inactivos los sistemas de la base de datos de origen. Esto significa que no se pueden realizar modificaciones a los datos en la base de datos de origen y que el registro de transacciones no recibe entradas de modificación adicionales.
- Esperar a que todos los cambios migren a las bases de datos de destino. Este proceso es el desvío real de los cambios.
- Después de que se completa el desvío, se crea una copia de seguridad de las bases de datos de destino con el fin de tener un punto de partida definido para las futuras copias de seguridad incrementales.
El resultado de la fase de desvío es que los sistemas de la base de datos de origen y los de destino están sincronizados, y no se producirán modificaciones de datos.
Para garantizar que se completó el desvío, se puede escribir un elemento de datos de “última inserción” en una base de datos de origen. Una vez que aparece el elemento de datos de “última inserción” en la base de datos de destino correspondiente, se completa la fase de desvío.
Fase 4: Cambio
Una vez finalizada la fase de desvío, puedes cambiar los clientes de las bases de datos de origen a las de destino. Estas son las prácticas recomendadas:
- Antes de habilitar el acceso a la base de datos de producción, prueba la funcionalidad básica para asegurarte de que los clientes funcionen y se comporten según lo previsto. La cantidad de casos de prueba determinará el tiempo de inactividad real para la base de datos de producción.
- Crea una copia de seguridad de las bases de datos de destino antes de habilitar el acceso a los clientes. Esta práctica recomendada garantiza que el estado inicial de las bases de datos de destino sea recuperable.
Al final del cambio, los clientes funcionan completamente y comienzan a acceder a las bases de datos de producción (que en este documento se denominaron bases de datos de destino hasta este punto).
Fase 5: Eliminación de bases de datos de origen
Después de completar el cambio a las bases de datos de producción, puedes borrar las bases de datos de origen. Se recomienda realizar una copia de seguridad final de cada base de datos de origen a fin de tener un estado final definido al que se pueda acceder. Es posible que las regulaciones de datos también requieran copias de seguridad finales por motivos de cumplimiento.
Fase 6: Resguardo
Implementar un resguardo, en particular para clientes de bases de datos muy críticos, puede ser una buena protección contra los errores y los problemas de la migración. Un resguardo es como una migración, pero a la inversa. Es decir, en un resguardo, configuras una migración de las bases de datos de destino a las bases de datos de origen. Con las migraciones de bases de datos heterogéneas, el resguardo es más complejo. Por este motivo, recomendamos realizar el cambio solo después de probar de manera exhaustiva que el proceso de migración de la base de datos y las aplicaciones conectadas a la base de datos de destino cumplan con los Acuerdos de Nivel de Servicio (ANS).
Después de desviar las bases de datos de origen y crear una copia de seguridad de todas, puedes habilitar los procesos de migración que identifican cambios en las bases de datos de destino y los migran a las bases de datos de origen antes del cambio.
Compilar estos procesos de migración garantiza que, luego de que los clientes realicen cambios en las bases de datos de destino, las bases de datos de origen se mantengan actualizadas. Es posible que se requiera un resguardo días o semanas después del cambio. Por ejemplo, es posible que los clientes accedan a la funcionalidad por primera vez y esté bloqueada debido a una funcionalidad que no se puede corregir de forma rápida. En este caso, los clientes pueden volver a acceder a las bases de datos de origen. Antes de volver a cambiar los clientes, se deben desviar todos los cambios en las bases de datos de destino a las bases de datos de origen.
En este enfoque, algunas circunstancias requieren atención especial:
- Debes diseñar esquemas de destino para que sea posible realizar una migración inversa (de las bases de datos de destino a las bases de datos de origen). Por ejemplo, si tu proceso de migración inicial (de origen a destino) tiene uniones o agregaciones, una migración inversa no es trivial ni imposible. En ese caso, los datos individuales también deben estar disponibles en las bases de datos de destino.
- Podría surgir un problema en el que las bases de datos de origen tienen registros de transacciones, pero las bases de datos de destino no proporcionan esa característica no funcional. En este caso, una migración inversa (de destino a origen) debe basarse en consultas diferenciales. Esa configuración debe diseñarse y prepararse en los esquemas de las bases de datos de destino.
- Los clientes que en un comienzo operaban en las bases de datos de origen deben estar disponibles y en funcionamiento para que puedan activarse en un resguardo. Cualquier cambio funcional que se realice en los clientes que acceden a las bases de datos de destino también se debe realizar en los clientes que acceden a la base de datos de origen para garantizar la equivalencia funcional.
Si bien un resguardo es un último recurso, la implementación de un resguardo es esencial y debe tratarse como una migración de base de datos completa, lo que incluye pruebas.
Cambios dinámicos durante la migración
En general, las bases de datos son sistemas dinámicos que los valores de esquema y de datos pueden cambiar. Los esquemas de la base de datos pueden cambiar en función de factores como los requisitos empresariales, y los valores de los datos pueden modificarse junto con los cambios del esquema o de manera independiente a ellos. Los cambios en los valores de datos pueden ocurrir de manera dinámica en cualquier momento con los cambios correspondientes de la implementación de una aplicación. En las siguientes secciones, se analizan algunos de los posibles cambios y lo que implican para una migración de bases de datos.
Cambios de esquema
Las bases de datos se pueden clasificar en sistemas que requieren un esquema predefinido, que tienen un esquema libre o que no tienen esquema. En general, los sistemas que requieren un esquema predefinido admiten operaciones de cambio de esquema, por ejemplo, agregar atributos o columnas en un sistema relacional.
En estos sistemas, controlas los cambios a través de un proceso de administración de cambios. Un proceso de administración de cambios permite realizar cambios de manera controlada. Cualquier operación que dependa del esquema, como las consultas o los procesos de migración de datos, se cambian de manera simultánea para garantizar un cambio coherente general.
Los sistemas de bases de datos que no requieren un esquema predefinido se pueden cambiar en cualquier momento. El cambio de esquema puede realizarlo un usuario autorizado y, en algunos casos, es posible hacerlo de manera programática. En estos casos, un cambio de esquema puede ocurrir en cualquier momento. Las operaciones que dependen del esquema pueden fallar, por ejemplo, las consultas o los procesos de migración de datos. Para evitar cambios de esquema no controlados en estos sistemas de bases de datos, debes implementar un proceso de administración de cambios como una convención y una regla aceptada en lugar de hacerlo mediante la aplicación del sistema.
Cambios de datos
En general, los esquemas controlan los valores de datos posibles para los distintos atributos de datos. Los sistemas sin esquema no tienen restricciones sobre los valores de datos.
En cualquier caso, pueden aparecer valores de datos que no se almacenaron antes. Por ejemplo, los tipos de enumeración a menudo se implementan como un conjunto de strings en sistemas de bases de datos. A nivel del lenguaje de programación, estos pueden implementarse en los clientes como tipos de enumeración verdaderos, aunque no es necesario. Es posible que un cliente almacene lo que considera un valor de enumeración válido y otros clientes no lo consideran como tal. Además, un proceso de migración de datos podría poner en clave su funcionalidad fuera de los valores de enumeración. Si aparecen valores nuevos, el proceso de migración de datos podría fallar.
Otro ejemplo se encuentra en el almacenamiento de estructuras JSON. En muchos casos, las estructuras JSON se almacenan en una string de tipo de datos; sin embargo, esos valores se interpretan como valores JSON cuando se accede. Si la estructura JSON cambia, el sistema de bases de datos no lo detecta; los procesos de migración de datos que interpretan una string como un valor JSON podrían fallar.
Cambios en el proceso de migración
La administración de cambios durante una migración de bases de datos en proceso es difícil y compleja, y puede generar fallas en la migración de datos o inconsistencias en ellos. Es óptimo que los cambios necesarios se retrasen hasta el final de la fase de desvío, momento en el que se sincronizan los sistemas de base de datos de origen y de destino. Los cambios en este punto se limitan a las bases de datos de destino y sus clientes (a menos que también se implemente un resguardo).
Si necesitas cambiar el proceso de migración durante una migración de datos, te recomendamos que mantengas los cambios al mínimo y, si es posible, que realices varios cambios pequeños en lugar de uno más complejo. Además, puedes considerar probar primero esos cambios mediante instancias de prueba de las bases de datos de origen y de destino. Lo ideal es que cargues la fuente de prueba con los datos de producción que luego migrarás al destino de prueba. Mediante este enfoque, puedes verificar los cambios propuestos sin afectar la migración de producción en curso. Después de probar y verificar los cambios, puedes aplicarlos a tu sistema de producción.
Para que los cambios sean posibles durante una migración de datos en curso, debes poder detener el sistema de migración de datos y reiniciarlo, quizás con procesos de migración de datos modificados. En ese caso, no tienes que comenzar desde el principio con una fase de carga de datos inicial. Si el sistema de migración de datos admite una función de ejecución de prueba, también puedes usarla.
Te recomendamos que evites cambiar el esquema, los valores de datos o los procesos usados durante una migración de datos. Si debes realizar cambios, puedes considerar reiniciar la migración de datos desde el principio para asegurarte de tener un estado de inicio definido. En cualquier caso, es fundamental que para la prueba usas datos de producción y hagas una copia de seguridad de las bases de datos antes de aplicar cambios de modo que, si es necesario, puedas restablecer el sistema general a un estado coherente.
Mitigación de errores de la migración
Pueden ocurrir problemas inesperados durante la migración de una base de datos. A continuación, se destacan algunas áreas que pueden requerir una planificación previa:
- Capacidad de procesamiento insuficiente. Un sistema de migración puede no tener suficiente capacidad de procesamiento a pesar de las pruebas de carga. Este problema puede tener muchas causas, como un aumento imprevisto de la tasa de cambios en la base de datos de origen o una limitación de la red. Puedes prepararte para esta situación mediante recursos adicionales a fin de realizar un escalamiento vertical dinámico o un escalamiento horizontal de todos los componentes involucrados.
- Inestabilidad de la base de datos. Las bases de datos de origen o de destino pueden presentar 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 deban recuperarse con frecuencia. En este caso, un cambio intencional de HA o DR puede solucionar el problema. Un cambio modifica el entorno no funcional (máquinas y almacenamiento) y puede ayudar a mitigar el problema. En este caso, debes probar los procesos de cambios y de recuperación de la migración de bases de datos para asegurarte de que el cambio no produzca incoherencias de datos en 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 comprender qué partes de un sistema de bases de datos se pueden volver a configurar de forma dinámica para abordar las limitaciones de recursos a medida que surjan. Si ciertos aspectos no se pueden configurar de forma dinámica, el tamaño inicial debe determinarse con cuidado.
Si realizas pruebas realistas y completas por adelantado, es muy probable que encuentres problemas potenciales con anticipación.
Próximos pasos
- Consulta los siguientes recursos sobre la migración de bases de datos:
- Consulta Migración de bases de datos para obtener más guías de migración de bases de datos.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.