Migrar una base de datos de un motor a otro, por ejemplo de Oracle o Informix a PostgreSQL, parece a primera vista un problema simple: convertir el esquema, traducir el c\u00f3digo SQL y trasladar los datos. Si fuera solo eso, las migraciones ser\u00edan sencillas. Pero en un sistema real alrededor de la base de datos hay todo un ecosistema de aplicaciones, procesos batch, ETL, data warehouses y otros sistemas que dependen de ella, directa o indirectamente.<\/p>\n\n\n\n
Por eso conviene plantear la migraci\u00f3n como un proceso de ingenier\u00eda basado en pruebas, mediciones e iteraciones sucesivas<\/strong>. En este art\u00edculo veremos cinco aspectos: disponer de una referencia objetiva del sistema actual, migrar y automatizar la conversi\u00f3n del esquema y los datos, probar todas las aplicaciones dependientes, preparar el switchover y un backup plan, y monitorizar y operar el nuevo sistema.<\/p>\n\n\n\n Antes de empezar necesitamos un conjunto representativo de pruebas funcionales y de rendimiento del sistema actual, incluidas pruebas de carga que reproduzcan en lo posible las condiciones reales. Que una aplicaci\u00f3n funcione con uno o dos usuarios no dice nada de c\u00f3mo se comportar\u00e1 con cientos de operaciones concurrentes.<\/p>\n\n\n\n Ejecutamos esas pruebas sobre el sistema original para obtener una referencia y las repetimos sobre el nuevo tras la migraci\u00f3n. Las diferencias nos dicen d\u00f3nde hay un problema real. Si una consulta que tardaba 200 ms sigue tardando lo mismo, no hay nada que resolver. Si pasa a tardar cinco segundos, tenemos un problema concreto, medible y reproducible.<\/p>\n\n\n\n medir \u2192 migrar \u2192 probar \u2192 detectar diferencias \u2192 corregir \u2192 volver a medir<\/strong><\/p>\n\n\n\n As\u00ed evitamos uno de los errores m\u00e1s habituales: dedicar semanas a problemas hipot\u00e9ticos, como optimizar consultas que sospechamos que ir\u00e1n peor o modificar aplicaciones anticip\u00e1ndonos a fallos que quiz\u00e1 nunca lleguen, mientras los problemas reales siguen ocultos.<\/p>\n\n\n\n Con la referencia inicial ya podemos migrar. Migrar el esquema es m\u00e1s que crear tablas: hay que identificar todos los objetos del sistema original que tengan correspondencia en PostgreSQL, directa o mediante alguna transformaci\u00f3n. Eso incluye tipos de datos, tablas, restricciones, \u00edndices, secuencias y otros mecanismos de generaci\u00f3n de identificadores, vistas, triggers, funciones, procedimientos almacenados y, por supuesto, los datos.<\/p>\n\n\n\n Los objetos no presentan la misma dificultad. Las tablas y los datos suelen ser relativamente directos, y seg\u00fan el volumen podemos usar scripts propios, herramientas ETL o conversores. Las vistas y, sobre todo, las funciones, procedimientos y triggers son otra cosa. El lenguaje procedural de Oracle o Informix difiere del de PostgreSQL en sintaxis, tipos, funciones disponibles, cursores, tratamiento de excepciones y algunos comportamientos propios de cada motor. Aqu\u00ed estamos traduciendo c\u00f3digo de un lenguaje a otro<\/strong>.<\/p>\n\n\n\n La traducci\u00f3n puede hacerse a mano, con ayuda de un LLM, con un producto basado en reglas y heur\u00edsticas o con un transpiler. Un transpiler es un traductor entre ambos lenguajes: si conoce formalmente origen y destino, aplica una regla conocida para generar el equivalente, y la transformaci\u00f3n es determinista, a diferencia del car\u00e1cter probabil\u00edstico de un LLM. No hay que elegir una sola opci\u00f3n. Podemos automatizar la mayor\u00eda de los casos, apoyarnos en una IA para otros y reservar la intervenci\u00f3n manual para los que realmente la necesiten.<\/p>\n\n\n\n Esta migraci\u00f3n no se har\u00e1 una sola vez. La repetiremos muchas veces, y cada ejecuci\u00f3n incorporar\u00e1 las correcciones de la anterior, nuevas reglas de traducci\u00f3n y mejoras en la transferencia de datos. Por eso conviene automatizar todo lo posible desde el principio. Si cada iteraci\u00f3n nos obligara a traducir a mano cientos de objetos y a recordar una secuencia de operaciones, el procedimiento ser\u00eda lento, dif\u00edcil de reproducir y propenso a errores.<\/p>\n\n\n\n Cuando aparezca un error de traducci\u00f3n, es preferible corregir el mecanismo que lo gener\u00f3 y no solo el resultado. Si veinte funciones usan una misma construcci\u00f3n mal traducida, podr\u00edamos corregir las veinte a mano, pero es mejor modificar el traductor para que la siguiente iteraci\u00f3n las genere bien. Cada problema resuelto mejora el proceso completo, y el d\u00eda de la migraci\u00f3n definitiva no haremos nada nuevo: ejecutaremos una vez m\u00e1s un procedimiento que ya hemos realizado y corregido muchas veces.<\/p>\n\n\n\n Con el esquema y los datos migrados llega probablemente la fase m\u00e1s laboriosa: comprobar que siguen funcionando todos los sistemas que dependen de esa base de datos<\/strong>. Que PostgreSQL tenga las tablas, que los datos est\u00e9n presentes y que las funciones compilen no es suficiente. Tiene que funcionar el sistema completo.<\/p>\n\n\n\n Hay que probar las aplicaciones de usuario, los servicios backend, los procesos batch, las tareas de cron u otros planificadores, los ETL, los sistemas de reporting, los data warehouses y cualquier otro sistema que lea o modifique datos de esa base. Estas pruebas nos dir\u00e1n qu\u00e9 aplicaciones necesitan adaptaci\u00f3n. Si una aplicaci\u00f3n funciona contra PostgreSQL y supera las pruebas funcionales y de rendimiento, no hay motivo para tocarla.<\/p>\n\n\n\n Cuando aparezcan incompatibilidades, las modificaciones pueden hacerse a mano, con ayuda de una IA o con herramientas que detecten SQL y traduzcan ciertas construcciones. Esta parte es m\u00e1s complicada de lo que parece. El SQL de una aplicaci\u00f3n no siempre es una sentencia identificable en el c\u00f3digo: puede estar repartido entre cadenas, oculto tras un ORM, definido en ficheros de configuraci\u00f3n o construido din\u00e1micamente a partir de par\u00e1metros. Incluso puede haber consultas complejas generadas al vuelo que dependan de los datos de entrada, de modo que la sentencia completa solo existe durante la ejecuci\u00f3n.<\/p>\n\n\n\n Por eso, aunque dispongamos de an\u00e1lisis est\u00e1tico del c\u00f3digo fuente, seguiremos necesitando las pruebas, que revelar\u00e1n los casos que el an\u00e1lisis no localiz\u00f3.<\/p>\n\n\n\n Cada modificaci\u00f3n de esta fase debe quedar registrada. Lo l\u00f3gico es usar un sistema de control de versiones como Git y, cuando convenga, mantener ramas espec\u00edficas de la migraci\u00f3n. As\u00ed cada iteraci\u00f3n parte de la anterior en lugar de reconstruir los cambios, sabemos exactamente qu\u00e9 se ha modificado y distintos equipos pueden revisarlo, probarlo y revertirlo si hace falta. En proyectos con decenas de aplicaciones implicadas, esta disciplina es especialmente importante.<\/p>\n\n\n\n Cuando hayamos migrado las bases de datos, adaptado las aplicaciones y superado las pruebas funcionales, de rendimiento y de carga, podremos plantear el paso a producci\u00f3n. A estas alturas ya conocemos la ventana de tiempo disponible para el cambio<\/strong>, y tras varias iteraciones sabemos cu\u00e1nto tarda realmente la migraci\u00f3n de los datos. Podemos dise\u00f1ar el switchover con medidas obtenidas en las pruebas y no con estimaciones.<\/p>\n\n\n\n Seg\u00fan el volumen de datos y la ventana disponible, podemos hacer una migraci\u00f3n completa durante el switchover o dejar migrada de antemano una parte y transferir solo lo pendiente. La migraci\u00f3n completa simplifica el procedimiento, pero puede exigir una ventana demasiado grande. La parcial o incremental la reduce, a cambio de m\u00e1s complejidad. Tambi\u00e9n podemos reducir tiempos con m\u00e1s recursos o paralelizando operaciones. Hay un compromiso entre tiempo, recursos y complejidad: cuanto menor sea la ventana, m\u00e1s complejidad habr\u00e1 que asumir.<\/p>\n\n\n\n Mover cientos de millones de registros entre dos motores parece cuesti\u00f3n de copiar tablas, pero con una ventana limitada se convierte en un problema de rendimiento. Las pruebas anteriores ya nos habr\u00e1n mostrado la forma m\u00e1s r\u00e1pida y fiable de hacerlo.<\/p>\n\n\n\n Durante la carga puede convenir eliminar o desactivar temporalmente lo que ralentice las inserciones: \u00edndices, ciertos constraints, checks o triggers. Tambi\u00e9n hay que usar los mecanismos de transferencia m\u00e1s r\u00e1pidos, como COPY en PostgreSQL. Y hay que mirar la salida: si la extracci\u00f3n desde Oracle o Informix es lenta, ella limitar\u00e1 todo el proceso.<\/p>\n\n\n\n Una vez transferidos los datos hay que reconstruir los \u00edndices, restaurar las restricciones eliminadas y comprobar que todo ha quedado bien configurado. Hay dos detalles f\u00e1ciles de olvidar. Si hemos cargado expl\u00edcitamente claves primarias generadas por secuencias o campos identity, hay que ajustar esos mecanismos para que las siguientes inserciones contin\u00faen desde el valor correcto. Y hay que ejecutar ANALYZE sobre las tablas cargadas, porque sin estad\u00edsticas actualizadas el optimizador puede elegir planes malos justo en las primeras horas en producci\u00f3n.<\/p>\n\n\n\n detener cambios \u2192 transferir datos \u2192 reconstruir, ajustar y analizar \u2192 validar \u2192 cambiar las aplicaciones<\/strong><\/p>\n\n\n\n Lo importante es que, llegado ese momento, ya hayamos ensayado todo el procedimiento: cu\u00e1nto tarda la transferencia, cu\u00e1nto la reconstrucci\u00f3n de \u00edndices, cu\u00e1nto duran las comprobaciones y cu\u00e1nto hace falta para volver a poner en marcha las aplicaciones.<\/p>\n\n\n\n Debemos asumir que el switchover puede fallar. Por eso necesitamos un backup plan<\/strong>, el plan de contingencia que ejecutaremos si todo falla. Aqu\u00ed no hablamos de copias de seguridad de la base de datos.<\/p>\n\n\n\n La decisi\u00f3n clave es qu\u00e9 hacer con las transacciones realizadas en el nuevo sistema si luego hay que volver al antiguo. Mientras PostgreSQL no acepte escrituras, ambos mundos se mantienen separados con facilidad. El problema aparece cuando empiezan a hacerse transacciones nuevas. Entonces hay que responder a una pregunta t\u00e9cnica y de negocio:<\/p>\n\n\n\n \u00bfPodemos permitirnos perder esas transacciones si tenemos que volver al sistema anterior?<\/strong><\/p>\n\n\n\n En algunos sistemas puede ser aceptable, porque las operaciones podr\u00edan repetirse o reconstruirse, o su volumen ser\u00eda tan peque\u00f1o que se recuperar\u00edan de otra forma. En otros, perder una sola transacci\u00f3n es inadmisible, y el backup plan tendr\u00e1 que incluir un mecanismo para conservarlas o trasladarlas de vuelta al sistema anterior.<\/p>\n\n\n\n Tambi\u00e9n podemos prever un periodo intermedio tras el switchover. Si el negocio lo permite, mantenemos el nuevo sistema en solo lectura, o con determinadas escrituras, mientras comprobamos que las aplicaciones funcionan y que el comportamiento es el esperado. Ser\u00eda una cuarentena. Mientras no se hayan generado transacciones nuevas, volver al sistema anterior sigue siendo relativamente sencillo. Muchos sistemas no podr\u00e1n permitirse una ventana prolongada en solo lectura, pero cuando sea posible da un margen adicional antes de cruzar el punto m\u00e1s delicado: permitir escrituras reales en producci\u00f3n.<\/p>\n\n\n\n El switchover y el backup plan tienen que dise\u00f1arse conjuntamente.<\/p>\n\n\n\n Este punto tiene que empezar antes de que termine el anterior. Cuando iniciemos el switchover, la monitorizaci\u00f3n de PostgreSQL debe estar instalada, configurada y probada. Tenemos que poder observar el rendimiento general, las consultas lentas, los errores, las sesiones, las conexiones, las transacciones, los bloqueos, las esperas, la CPU y la memoria, el I\/O, el almacenamiento y, cuando existan, la replicaci\u00f3n y la alta disponibilidad.<\/p>\n\n\n\n Esa informaci\u00f3n ser\u00e1 especialmente valiosa en las primeras horas y d\u00edas. Si aparece un problema, necesitaremos saber qu\u00e9 ocurre para decidir si podemos resolverlo o si es el momento de activar el backup plan. Volvemos al principio: medir antes de actuar. Decir que PostgreSQL \u00abparece ir lento\u00bb sirve de poco. Necesitamos saber qu\u00e9 consulta se ha ralentizado, qu\u00e9 sesiones esperan, qu\u00e9 bloqueos hay, qu\u00e9 pasa con el I\/O o qu\u00e9 errores reciben las aplicaciones.<\/p>\n\n\n\n Detectar un problema de poco sirve si no sabemos resolverlo. Antes de llegar a producci\u00f3n tenemos que dominar la operativa habitual y de emergencia de PostgreSQL: backups, restores, recuperaci\u00f3n, alta disponibilidad, replicaci\u00f3n, arranque y parada de servidores, gesti\u00f3n de usuarios y conexiones, bloqueo temporal de accesos, terminaci\u00f3n de sesiones, diagn\u00f3stico de bloqueos y an\u00e1lisis de consultas problem\u00e1ticas. Al llegar al switchover tenemos que ser DBA competentes en PostgreSQL<\/strong>.<\/p>\n\n\n\n Idealmente conoceremos el nuevo sistema al menos tan bien como el antiguo, y durante los primeros d\u00edas mejor preparados de lo habitual, porque entonces surgir\u00e1n situaciones que no vimos en las pruebas. Si hay un problema cr\u00edtico en producci\u00f3n, ese no es el momento de estudiar c\u00f3mo se diagnostica un bloqueo, c\u00f3mo se recupera un servidor o qu\u00e9 pasa si se reinicia un servicio.<\/p>\n\n\n\n Por eso, durante el switchover y los primeros d\u00edas puede ser muy recomendable contar con especialistas con experiencia real administrando PostgreSQL en producci\u00f3n. Lo valioso es que, adem\u00e1s de conocer el producto, est\u00e9n acostumbrados a diagnosticar problemas de rendimiento, concurrencia, recuperaci\u00f3n y alta disponibilidad en sistemas reales. Con el tiempo, el equipo interno ganar\u00e1 esa experiencia, pero los primeros d\u00edas son aquellos en los que una decisi\u00f3n equivocada cuesta m\u00e1s.<\/p>\n\n\n\n La migraci\u00f3n termina cuando podemos observar el sistema, entender lo que ocurre y reaccionar correctamente cuando algo no funciona como esper\u00e1bamos<\/strong>. Que PostgreSQL empiece a recibir conexiones es solo un paso intermedio.<\/p>\n\n\n\n Migrar de un motor de base de datos a otro no es trivial. Estamos sustituyendo una de las piezas centrales de un sistema inform\u00e1tico, y por eso el proceso debe ser controlado, medible y repetible. Quienes hemos hecho este tipo de proyectos sabemos que se puede hacer bien, y tambi\u00e9n que es muy f\u00e1cil infravalorarlo si se ve solo como un problema de conversi\u00f3n de bases de datos.<\/p>\n\n\n\n medir \u2192 migrar \u2192 probar \u2192 detectar \u2192 corregir \u2192 repetir<\/strong><\/p>\n\n\n\n Con buenas pruebas sabremos qu\u00e9 funciona y qu\u00e9 no. Con la migraci\u00f3n automatizada podremos repetirla las veces necesarias. Probando todas las aplicaciones sabremos cu\u00e1les necesitan cambios. Y con un switchover ensayado, un backup plan y un equipo que sabe operar el nuevo motor, el paso a producci\u00f3n deja de ser una apuesta y pasa a ser un procedimiento conocido.<\/p>\n\n\n\n En el caso de PostgreSQL creemos que s\u00ed. Es un sistema gestor maduro, muy fiable y con excelente rendimiento, especialmente en cargas transaccionales. Seg\u00fan el sistema de partida, el ahorro puede ser considerable: en instalaciones grandes las licencias, el mantenimiento y el soporte de ciertos proveedores suman cifras muy importantes, y una migraci\u00f3n bien planteada puede amortizarse eliminando buena parte de esos costes.<\/p>\n\n\n\n Otra ventaja es que PostgreSQL es software libre y de c\u00f3digo abierto<\/strong>. Podemos estudiar su c\u00f3digo, entender el optimizador, analizar c\u00f3mo implementa la concurrencia o investigar por qu\u00e9 toma una decisi\u00f3n. No hay que tratar el SGBD como una caja negra. Adem\u00e1s, a su alrededor hay un gran ecosistema de empresas, desarrolladores, DBA, consultores y proveedores, y se usa en sistemas de todo tipo, incluidos los cr\u00edticos y de gran tama\u00f1o.<\/p>\n\n\n\n Con todo, esas ventajas no deben llevarnos a minimizar el trabajo necesario. No queremos desanimar a nadie, al contrario: hay razones t\u00e9cnicas y econ\u00f3micas muy poderosas para migrar. Pero conviene conocer la dificultad de antemano y tratar la migraci\u00f3n como lo que es, un proyecto de ingenier\u00eda.<\/p>\n\n\n\n Los problemas aparecer\u00e1n. Lo importante es haber construido un procedimiento que nos permita encontrarlos antes de llegar a producci\u00f3n, medirlos, corregirlos y volver a probar. Con cada iteraci\u00f3n reducimos la incertidumbre, hasta que la migraci\u00f3n se convierte en un proceso que ya hemos ejecutado, medido y corregido muchas veces.<\/p>\n\n\n\n Se puede hacer y merece la pena, pero hay que hacerlo bien. Necesitamos haber hecho las pruebas suficientes para saber que funciona.<\/p>\n\n\n\n Una migraci\u00f3n de bases de datos no es un acto de fe. Es un proceso de ingenier\u00eda.<\/strong><\/p>\n\n\n\n1. Disponer de tests: medir antes de actuar<\/strong><\/h2>\n\n\n\n
2. Migrar el esquema y los datos<\/strong><\/h2>\n\n\n\n
Una migraci\u00f3n que vamos a repetir muchas veces<\/strong><\/h3>\n\n\n\n
3. Probar y adaptar todas las aplicaciones dependientes<\/strong><\/h2>\n\n\n\n
El SQL puede estar en cualquier parte<\/strong><\/h3>\n\n\n\n
Conservar todo lo que vayamos corrigiendo<\/strong><\/h3>\n\n\n\n
4. Preparar el switchover y el backup plan<\/strong><\/h2>\n\n\n\n
La migraci\u00f3n final de los datos<\/strong><\/h3>\n\n\n\n
La carga masiva es m\u00e1s compleja de lo que parece<\/strong><\/h3>\n\n\n\n
Preparar un backup plan<\/strong><\/h3>\n\n\n\n
Una posible cuarentena<\/strong><\/h3>\n\n\n\n
5. Monitorizar y saber operar el nuevo sistema<\/strong><\/h2>\n\n\n\n
Saber operar el sistema<\/strong><\/h3>\n\n\n\n
Dejarse acompa\u00f1ar por especialistas<\/strong><\/h3>\n\n\n\n
Migrar bases de datos con garant\u00edas: un proceso de ingenier\u00eda<\/h2>\n\n\n\n
Entonces, \u00bfmerece la pena?<\/strong><\/h3>\n\n\n\n
Preguntas frecuentes sobre la migraci\u00f3n de bases de datos<\/h2>\n\n\n\n