MIGRACIONES FROM HELL (II): Preparando un Drupal 6 como origen de datos

rojomorgan migraciones drupal
MIGRACIONES FROM HELL (II): Preparando un Drupal 6 como origen de datos

En nuestro anterior artículo de la serie “Migraciones from Hell”, ya dimos cuenta de un primer acercamiento al movimiento de exportación - importación de contenidos de un sitio web a otro basándonos en operaciones de site-building usando los módulos disponibles de la familia Feed a tal efecto y considerando que se mueven entre dos Drupales 7 con TdC similares, en un escenario bastante controlado y sencillo.  

En este artículo vamos a avanzar un poco más ofreciendo un escenario más complejo cuando trabajamos con otras versiones y proyectos de tipo “legacy”, algo que es frecuente al trabajar con servicios de mantenimiento y soporte en Drupal. 
Dejaremos para otro artículo las migraciones más avanzados a partir de Migrate API de Drupal 8. ¿Preparados? vamos a modelar un proceso inicial de migración entre un Drupal 6 algo vetusto y un Drupal 7, basándonos en herramientas disponibles a nivel de módulos en un escenario muy determinado a nivel de versiones y recursos (cada migración tiene un contexto específico que requiere criterios adaptados).  

En primer lugar y antes que cualquier otra cosa, deberías establecer el plan de migración, esto es, realizar un mapa de acciones a alto nivel que luego podrías ir describiendo de manera más detallada para tener una visión lo más global posible de todo lo que debes realizar, un boceto de los procedimientos que te planteas seguir para llevar la migración a buen puerto. 

Escenario: Migración entre un Drupal 6 (origen) y un Drupal 7 (destino), con prisa (para ayer) y sin demasiados recursos a tu disposición. 

Objetivo: Estabilizar el proceso y tener controlada la contingencia. 

¿Qué necesitamos para planificar la migración? De cara a preparar el proceso de trabajo, necesitamos al menos un esbozo metodológico a nivel general que nos aporte la suficiente información:

1- Input del sitio web de origen
¿Qué datos necesitaré para trabajar en esta migración?
¿Dónde está qué? 

2- Acciones
Acciones iniciales: Antes que cualquier otra cosa ¿Qué hay que hacer?
Determinar el formato del dataset: ¿Cómo vamos a manejar los datos?
¿Qué set de herramientas usaremos? 
¿Cómo exportar?
¿Qué procesamiento intermedio requieren los datos?
¿Cómo vamos a gestionar la importación?

 

3- Establecimiento del cotejo
¿Cómo vamos a ir cotejando el proceso? 
¿Cómo haremos seguimiento de los pasos para ver que todo va yendo relativamente bien?

4- Mecanismos de validación
¿Cómo daremos por buena la migración? 
¿Qué items tendremos que validar para obtener un “ok” final?

 

Y en particular, para preparar una migración a partir de una versión antigua de Drupal, recomendamos seguir los siguientes pasos:

1- Gestionar Dumps de la base de datos

De cara a todas las acciones, pruebas y decisiones que tendrás que tomar, es muy importante realizar dumps de la base de datos original de manera periódica. No importa si el sitio web Drupal 6 (el origen) está en producción (que no debería) o si se encuentra en un entorno de trabajo interno: la base de datos de Drupal recopila mucha más información que la concerniente a los nodos: configuraciones, módulos, etc. Si vas experimentando (ojalá que sea en un entorno interno controlado) y se producen problemas, lo mejor será volver a levantar el último dump que tengas disponible: sé consciente de que vas caminando por un terreno algo inestable que podría darte algún susto. 

Extrae tanto usuario como contraseña de base de datos. Podemos encontrarlos dentro del servidor del origen en el settings.php ubicado en /sites/default/, de tal manera:
/home/drupal_project/public_html/sites/default/settings.php

Allí en el fichero settings se encuentran los datos de conexión que necesitaremos: 

/* Database URL format: 
* $db_url = 'mysql://username:password@localhost/databasename'; 
* $db_url = 'mysqli://username:password@localhost/databasename'; 
* $db_url = 'pgsql://username:password@localhost/databasename';
*/

$db_url = 'mysql://usuario:contraseña@localhost/nombrebasededatos';
Y una vez hayas extraído los datos de la línea anterior, probamos a hacer el dump. La instrucción es sencilla, desde el terminal:

mysqldump -u user -p basededatos > nombredelarchivo.sql

y tendrás que introducir la contraseña a continuación.  Esto debería crearte el fichero de volcado con extensión .sql y ya tienes un dump para poner a salvo durante todo el proceso de migración. 

Recomendado: si bien con este dump te has salvado las espaldas, lo ideal es hacer un pequeño script en bash para realizar el dump de manera automática y luego programarlo mediante un cron para que se ejecute periódicamente y siempre tengas una copia actualizada de toda la base de datos del Drupal de origen. 

¿Cómo hacerlo? bueno no entra dentro del alcance del post PERO como es rápido y estamos en harina, vamos rápido a verlo:

Primero: Carpeta de almacenamiento de copias de seguridad
Creamos un directorio de destino de todos los volcados que iremos realizando periódicamente:

mkdir  /migraciondrupal/

Segundo: un pequeño script para realizar volcados de la base de datos

En nuestro editor de texto favorito escribimos el script que hará el backup de la bases de datos que tengamos en nuestro servidor de MySQL, un fichero llamado (por ejemplo) mysqlvolcados.sh  en home/usuario/scripts/ que contendrá las siguientes líneas de código:

#!/bin/sh
 mysqldump -u user -p password --opt basededatos > home/usuario/migraciondrupal/basededatos.sql
  cd /home/usuario/migraciondrupal/
 tar -zcvf backupsperiodicos_$(date +%d%m%y).tgz *.sql
 find -name '*.tgz' -type f -mtime +2 -exec rm -f {} ;

Donde mediante el orden de comandos introducidos le indicamos lo siguiente:

1- mysqldump: para ejecutar el volcado en la dirección indicada.
2- cd: cambio al directorio que contiene los volcados
3- tar: empaquetamos en un comprimido cada dump añadiendo la fecha al nombre
4- find + rm: localiza copias creadas con dos días de antigüedad y las elimina. 

Permisos de ejecución al nuevo script:
sudo chmod 755 mysqlvolcados.sh

Tercero: un cron (una tarea programada corriendo en background al estilo daemon) con la ejecución programada del script anterior a través de crontab.
Lanzando por consola crontab -e se abrirá el crontab con el editor de texto configurado en nuestro sistema. aquí agregamos la siguiente línea y guardamos nuestro archivo:

0 1 * * * /home/usuario/scripts/mysqlvolcados.sh

y dado que por definición la estructura de un archivo de crontab tiene el siguiente formato:
Minutos (rango de 0-59)
Horas (0-23)
Día del mes (1-31)
Mes (1-12)
Día de la semana (0-6 siendo 0=Domingo)
Ruta completa al script o programa que queramos ejecutar
Cualquier campo dejado con * quiere decir que corre con cualquier posible valor para ese campo. 

En este caso hemos configurado el crontab para correr todos los días del año durante los doce meses de este a la 01:00 de la madrugada: podría ser 356 dumps almacenados, pero ya nos aseguramos en el script que se eliminaran los que tuviesen dos días de antigüedad.

 

2- Supervisar el estado de los datos y las tablas

Y ahora sí, sigamos. Nos habíamos quedado en el dump, pero es probable que al ser el origen un Drupal 6 vetusto, la base de datos esté más quemada que el mapa de Bonanza. Es muy importante que antes de programar dumps mediante crontabs realicemos algunas pruebas directas, ya que a veces al lanzar el dump, obtenemos por consola:

mysqldump: Got error: 145: Table './base_de_datos/cache_page' is marked as crashed and should be repaired when using LOCK TABLES. 

Esto quiere decir que hay datos y tablas corruptas que hay que reparar y  pueden empezar a surgir problemas. Pero keep calm: Es posible que existan varias tablas corruptas a la hora de hacer el Dump de la base de datos. Por suerte existen varias opciones para las reparaciones parciales de tablas, bien desde la consola propia del prompt de MySQL o bien desde PHPMyAdmin de manera gráfica. Pero repasemos primero un poco el contexto de este problema para su mejor comprensión. 

MyISAM e InnoDB han sido durante muchos años las opciones a nivel de motor de base de datos disponibles para MySQL. Cada una con sus ventajas y sus inconvenientes relacionadas con contextos específicos (MyISAM con más velocidad para la recuperación de datos vía SELECT e InnoDB más indicada para operaciones de INSERT/UPDATE). En el caso de MyISAM se construyen tres ficheros de manera complementaria a una tabla: el fichero de extensión .frm para almacenar el formato de la tabla, el .MYD para almacenar los datos en sí y el fichero .MYI para guardar el index. Es bastante probable que se corrompan datos y tablas, y esto bloquee procesos como los de gestionar Dumps que veíamos en el apartado anterior.  Para resolver estas situaciones tenemos tres opciones:

Primero: Se puede dar una orden sencilla de reparación tabla a table mediante el prompt de MySQL por consola, del tipo: mysql> repair table watchdog; lo cual resolverá la reparación de la tabla de manera directa con la limitación de que es posible que tras este error 145 en esa tabla, aparezcan los siguientes. Por eso recomendamos realizar también la siguiente opción. 

 

Segundo: Usar myisamchk como comando y utilidad de checkeo y reparación de tablas en casos MyISAM. Para ello, tenemos dos usos directos:

1- Volcado de todas las tablas corruptas de la base de datos en un fichero de texto:

$ myisamchk /var/lib/mysql/basededatos/*.MYI >> /tmp/myisamchk_log.txt

2- Reparaciones masivas en la base de datos:

$ myisamchk --silent --force --fast --update-state /var/lib/mysql/basededatos/*.MYI

Aquí puedes consultar todas las opciones del uso del comando myisamchk: https://dev.mysql.com/doc/refman/5.7/en/myisamchk.html

 

Tercero: Reparar tablas desde la interfaz de phpmyadmin

 

Una vez que sepamos que tablas están corruptas, podemos lanzar una acción en lote desde la interfaz de phpmyadmin para lanzar reparaciones:

 

3- Cohesionar versiones de módulos y dependencias

En este escenario que estamos siguiendo en el que te planteas un Drupal 6 como origen de datos, es bastante probable que decidas acometer una exportación de datos a partir del origen para realizar la migración. En ese caso necesitarás una suite de módulos  instalados para la exportación de datos y formatos disponibles, pero si la versión de Drupal 6 a migrar es suficientemente antigua, puedes tener algunas tareas de actualizaciones por resolver antes de exportar. 

Por ejemplo, un caso bastante normal cuando se trata de versiones antiguas es que use Views y que el módulo instalado responsable de la gestión de las vistas de la plataforma sea el mismo Views en su versión 6.x-2.12. Normalmente, cualquier opción que nos planteemos requiere integrarse con Views en su versión 6.x-3.2, por lo que tenemos un problema de compatibilidades en la plataforma de cara a realizar exportaciones masivas de datos desde el sitio web original realizado en Drupal 6. Por ejemplo, todas las versiones disponibles de Views Data Export funcionan con Views 3.2, por lo que resulta una herramienta de uso incompatible a no ser que realices una actualización lo más segura posible y bajo control del sitio web. 

Necesitas repasar primero las relaciones de depedencias entre módulos para poder instalar las herramientas que necesitas y que sean compatibles, 

Feeds 6.x-1.0-beta3
Requisitos:
ctools 6.x-1.15
https://www.drupal.org/project/feeds/releases/6.x-1.0-beta3

Feeds 6.x-1.0-beta4
Requisitos:
ctools 6.x-1.15
https://www.drupal.org/project/feeds/releases/6.x-1.0-beta4

-> Pero ctools 6.x-1.15 requiere Views 3.2

Node export 6.x-3.4
Requisitos:
uuid 6.x-1.0-rc2
features 6.x-1.2
https://www.drupal.org/project/node_export/releases/6.x-3.4

¿Cual es la mejor opción? Sin duda, el escenario ideal sería aquel en el que pudieses tener una copia de trabajo del sitio web basado en Drupal para hacer pruebas de actualización con Views a 3.2 en el caso de tener una versión anterior. Con esta actualización sería posible compatibilizar la instalación de View Data Export (https://www.drupal.org/project/views_data_export), un módulo preparado para realizar exportaciones masivas de datos partiendo de Views y tomando formatos tales como CSV, SML o incluso Microsoft DOC. 

2 Abril 2018 - 3:25pm
Total de votos: 5
Imagen de David Rodríguez
David Rodríguez

Añadir nuevo comentario

Plain text

  • No se permiten etiquetas HTML.
  • Las direcciones de las páginas web y las de correo se convierten en enlaces automáticamente.
  • Saltos automáticos de líneas y de párrafos.
CAPTCHA
Esta pregunta es para probar si eres o no un visitante humano.