Cuatro planteamientos distintos para migrar mysql cambiando de servidor

Migraciones con MySQL

Hay diferentes maneras de migrar de un servidor a otro una base de datos MySql. Hay factores como la versión, capacidad del servidor/res, volumen de datos, tiempo sin servicio y demás que nos limitan para elegir la mejor manera de hacerlo. También es otro factor si tenemos cluster, si migramos a un nuevo servidor etc. En este caso os expongo cuatro maneras de hacerlo para cambiar de servidor y/o versión.

  • Copy&paste
    Si tenemos la suerte que la versión de mysql será la misma que la actual podemos arriesgarnos a transferir los datafiles y binlogs(si es el caso) de un servidor a otro. No es del todo adecuada pero si paramos de forma correcta la base de datos en el momento de la copia no nos debería suponer ningún problema. Aquí el tiempo del corte vendrá determinado por la duración de la transferencia de archivos de un servidor a otro.
     
  • Upgrade+Copy+paste
    Si queremos hacer algo similar a lo anterior pero tenemos en el servidor actual una versión anterior a la nueva lo mejor que podemos hacer es actualizar la versión de MySql en origen antes de transferir los archivos a destino. Supone algo más de tiempo, entre que actualizamos y probamos, pero no debería suponer mayor problema.  
#mysql_upgrade --user root --password --force

 

  • Exportación e importación
    En algún caso por algún motivo especial necesitaremos hacer la migración mediante un dump usando mysqldump. Un ejemplo sería tener una base de datos con tablas innoDb que han crecido demasiado (gb) y nos interesa separar el fichero propio de innoDb de datos e índices y que nos quede uno por cada tabla (incluyendo inno_db_file_per_table). Aquí no hay más que reconstruir tabla  a tabla o directamente esperar al dump. De esta manera la duración del corte de servicio vendrá condicionado por el tiempo de generación del dump con mysqldump, su transferencia al otro servidor y la importación; pero adelanto que seguramente es la manera que más tiempo requiere. 
#exportamos todas las bbdd
# -A = alldatabases, -F = flush logs

mysqldump -A -F -u root --password


#importamos a saco todo el fichero
mysql -u root -p < dump.sql

 

  • Exportación e importación con replicación de por medio
    Si nos vemos forzados a hacer una migración “lógica” como en el caso anterior podemos hacer trampa y reducir el tiempo total quitando del corte la importación del dump. El corte nos quedará partido en dos: el dump e inicio de replicación en el servidor anterior y el cambio final de servidores una importada la información en destino y una vez el slave esté al dia en la replicación. Esta manera es algo más complicada pero solo se tienen que tener en cuentra cuatro cosas: hacer el dump bloqueando tablas o parando con -b, iniciar la replicación después, para el slave hecho el cambio y SOBRETODO comprobar la compatibilidad de la replicación si tenemos diferentes versiones de mysql entre master/slave y con la forma en la que insertamos datos (uso de funciones no determinísticas como USER() y alguna más no son compatibles). Más info sobre la replicación aquí.

 

Recapitulando, la última opción (d) nos permite reducir mucho el tiempo de la parada pero es algo más complicada. La primera es la más sencilla siempre que sea posible. Como he dicho antes hay factores que nos condicionan para elegir cualquier de estas u otras formas de hacerlo y también depende de las ganas de complicarnos que tengamos o sobretodo el tiempo que nos podamos permitir tener la base de datos parada. Para gustos colores...