Fecha: 2020-02-11 Tiempo de lectura: 4 minutos Categoría: Operaciones Tags: mongodb / mongodump / mongorestore
Cuando hacemos proyectos simples que requieren el uso de una base de datos mongodb es habitual poner un servidor simple y poco potente para salir del paso. A veces, estos proyectos empiezan a crecer en número y en importancia y necesitamos plantearnos su traspaso a hardware más potente o a una topología tipo cluster.
En estos casos nos encontramos con la necesidad de juntar bases de datos provenientes de varios servidores menores, y no es una tarea simple; podemos utilizar las facilidades de las replica sets para clonar un servidor en caliente, pero no de varios, ya que la nueva sincronización desecharía las sincronizaciones anteriores.
Antes podíamos utilizar helper copydb
adecuado para la ocasión, pero según la
documentación, esto va a dejar de ser una opción en un futuro próximo:
Deprecated since version 4.0: MongoDB deprecates copydb and its helper db.copyDatabase().
La recomendación por parte de los creadores es utilizar el combo mongodump
/ mongorestore
,
que se encadenarían utilizando unix pipes para no necesitar siquiera un fichero
intermedio. Ambos comandos funcionan con la salida y la entrada estándar, haciendo
este procedimiento fácil, y permitiendo incluso usar SSH como capa de transporte.
Tenemos dos proyectos: un blog y una tienda. Cada uno utiliza un servidor de mongodb distinto, distribuido de esta forma:
Por simplicidad, cada uno de estos servidores es una instancia solitaria de mongodb que expone su puerto 27017 a otros servidores de la red interna (que es donde están los servidores de aplicación).
Como sabemos, el comando mongodump
y el comando mongorestore
funcionan conectándose
a un servidor mongodb, ya sea en local o en remoto. A veces estos remotos no están
disponibles vía red por políticas de seguridad, o por formar parte de redes distintas.
Así que disponemos de varias opciones:
mongodump
en un fichero, moverlo de servidor y hacer el mongorestore
mongodump
y mongorestore
a través de SSH directamenteTRUCO: Los comandos mongodump
y mongorestore
funcionan con parámetros de red
individuales y con URIs con el flag --uri
. Esto nos permite poner orígenes y destinos
más complejos, como por ejemplo replica sets, autenticación o read preferences.
WARNING: Para que los comandos mongodump
y mongorestore
trabajen con la salida
y la entrada estándar necesitan el flag --archive
, sin especificar el destino; esto
hará que asuman la lectura y la escritura desde la consola.
Supongamos que server01 y server03 están en la misma red y se pueden comunicar por el puerto 27017 si restricciones. Este es el caso más simple. Basta con ejecutar los dos comandos en una máquina cualquiera especificando correctamente los servidores origen y destino (que por defecto serían localhost).
gerard@server01:~$ mongodump -d blog --archive --gzip | mongorestore -h server03 --archive --gzip --drop
...
gerard@server01:~$
Alternativamente podemos lanzar desde cualquier servidor que tenga las tools instaladas:
gerard@server03:~$ mongodump -h server01 -d blog --archive --gzip | mongorestore --archive --gzip --drop
...
gerard@server03:~$
gerard@adminserver:~$ mongodump -h server01 -d blog --archive --gzip | mongorestore -h server03 --archive --gzip --drop
...
gerard@adminserver:~$
Supongamos que server02 y server03 no son accesibles por red. Sin embargo,
como sysadmins tenemos acceso a ambos desde una máquina administrativa. El truco
es simple: lanzamos el mongodump
en la máquina origen por SSH y en la salida estándar;
luego utilizamos una unix pipe para insertar esa salida en la entrada de un
mongorestore
lanzado por SSH contra el servidor destino.
gerard@sirius:~$ ssh server02 mongodump -d shop --archive --gzip | ssh server03 mongorestore --archive --gzip --drop
...
gerard@sirius:~$
TRUCO: La máquina sirius no dispone de mongodump
ni mongorestore
instalados;
se ejecutan dichos comandos en los servidores server02 y server03 respectivamente.
Tras mover cada base de datos a server03, nuestras aplicaciones pueden cambiar su fuente de datos fácilmente (suponiendo que ese parámetro sea configurable), y si lo hemos hecho bien, ganaremos los beneficios por los que pusimos el nuevo servidor, que puede ser por alguno de los siguientes motivos:
TRUCO: Este traspaso de bases de datos puede ser gradual; podemos ir desmantelando servidores y reconfigurando las aplicaciones a medida que podamos. No es necesario mover todas las bases de datos de golpe.