En este artículo, mas que entrar en detalle con configuraciónes y distintos comandos, vamos a explicar unos pasos a seguir, para intentar evitar a nuestros usuarios, los inevitables efectos que surgen al migrar un site con base de datos incluida. Ocho sencillos pasos, que teniendolos en cuenta, evitarán la perdida de servicio durante una migración.

Preparar el servidor de detino.
Hay que tener listo el servidor de destino, configurado para mostrar el site que vamos a migrar, con su aplicación y base de datos, accediendo a ésta sin problemas. Utilizaremos backup de la aplicación y la bd para montarlo y modificando nuestro archivo de hosts (/etc/hosts en sistemas linux), apuntaremos el nombre de la web, a la nueva ip del servidor. De esta forma ya estaremos accediendo al servidor nuevo, cuando escribamos el nombre de la web en nuestro navegador y podremos comprobar que todo funciona correctamente, aunque con datos antiguos.
También será aconsejable preparar un usuario que pueda acceder a esta bd desde el servidor antiguo.

Cambiar el ttl de la zona.
Dos días antes de la migración (o tantos como el ttl actuar de la zona tenga), es aconsejable, cambiar el ttl de la zona del dominio que vamos a migrar a 2 horas. De esta forma, a los dos días, cuando hagamos el cambio, solo tendremos que esperar dos horas, una vez cambiemos el registro “a” del nombre de la web a la nueva ip del servidor.

Evitar todo acceso a la base de datos.
Es importante poner la base de datos en modo lectura, para que podamos hacer un backup consistente y actualizado de ésta. La aplicación seguirá funcionando, aunque no permitirá cambiós en la bd.

Hacer backup de la bd y restaurar.
Haremos un backup con la bd en modo lectura, lo que nos evitará cambios mientras se hace, logrando un backup consistente con los datos actualizados al último momento. Una vez realizada, tenemos que restaurarla en el nuevo servidor.

Cambiar la bd del antiguo servidor.
En la aplicación que corre en el antiguo servidor, haciendo uso del usuario que creamos en el primer paso para la base de datos, cambiaremos ésta y especificaremos la del nuevo servidor, ya en modo lectura/escritura. De esta forma nuestra aplicación seguirá visible y funcionando para todos nuestros usuarios que accedan por el servidor antiguo. Comprobamos que en éste, se ve todo correctamente y trabaja bien con la nueva bd.

Comprobamos el nuevo servidor.
En el nuevo servidor comprobamos que trabaja bien con la base de datos actualizada y si hiciese falta actualizar los archivos de la aplicación, este sería un buen momento.

Modificar el dns.
Nuestro nuevo server ya esta listo para servir la aplicación, solo queda que le enviemos todas las peticiones. Para ello modificar el registro “a” del nombre de la web, para que apunte a la nueva ip y volvemos a dejar el ttl con su valor original (normalmente 2 días).

Últimos detalles.
Dos horas después nuestro servidor nuevo debería de estar soportando toda la carga. Comprobamos en los logs del servicio web, que ya no llegan peticiones en el antiguo servidor, una vez esto ocurra, podemos apagarlo.
Es posible que necesitemos sincronizar los logs de acceso a la apliación de los dos servidores, ya que durante dos horas, estarán repartidos entre ambos, podemos hacer uso del comando sort, como indica en el link.

Con estos sencillos pasos, lograremos una migración casi transparante para los usuarios.