Saludos amigos, durante mucho tiempo os he ido contando todas las ventajas de InfluxDB, Telegraf, y Grafana como sistema de monitorización open-source.
Yo tenía montado todo mi stack (InfluxDB, Telegraf, y Grafana) en una VM simple con Ubuntu 16.04, pero desde hace unos meses he ido notando consumos desmesurados de RAM, kernel panics y otro tipo de situaciones que me han hecho pensar en mover todo hacía Ubuntu 18.04 LTS, que es mucho más estable, aparte de contar con un soporte mucho más activo.
Uno de los mayores problemas o incógnitas que tenía era cómo mover toda mi base de datos de InfluxDB con toda esta información de tantos años, y sobre ésto trata el blog post de hoy.
Realizando el Backup de InfluxDB Open-Source Edition
InfluxDB contine varios métodos para realizar backup y restore, para la versión Enterprise se pueden encontrar otros elementos más avanzados y más resiliciencia para proteger las Base de Datos. Para la versión open-source, la información oficial está aquí.
Básicamente, voy a realizar un backup de todas mis bases de datos a una carpeta en temp, de esta manera:
influxd backup -portable /tmp/backup
El resultado, que tardará más o menos dependiendo del tamaño de la base de datos, podemos ver en consola algo similar a lo siguiente:
2020/02/16 15:42:04 backing up metastore to /tmp/backup/meta.00 2020/02/16 15:42:04 No database, retention policy or shard ID given. Full meta store backed up. 2020/02/16 15:42:04 Backing up all databases in portable format 2020/02/16 15:42:04 backing up db= 2020/02/16 15:42:04 backing up db=_internal rp=monitor shard=1301 to /tmp/backup/_internal.monitor.01301.00 since 0001-01-01T00:00:00Z 2020/02/16 15:42:04 backing up db=_internal rp=monitor shard=1302 to /tmp/backup/_internal.monitor.01302.00 since 0001-01-01T00:00:00Z [...] 2020/02/16 15:42:05 backing up db=telegraf rp=default shard=347 to /tmp/backup/telegraf.default.00347.00 since 0001-01-01T00:00:00Z 2020/02/16 15:42:05 backing up db=telegraf rp=default shard=846 to /tmp/backup/telegraf.default.00846.00 since 0001-01-01T00:00:00Z 2020/02/16 15:42:05 backing up db=telegraf rp=default shard=2 to /tmp/backup/telegraf.default.00002.00 since 0001-01-01T00:00:00Z 2020/02/16 15:42:05 backing up db=telegraf rp=default shard=4 to /tmp/backup/telegraf.default.00004.00 since 0001-01-01T00:00:00Z 2020/02/16 15:42:11 backing up db=telegraf rp=default shard=12 to /tmp/backup/telegraf.default.00012.00 since 0001-01-01T00:00:00Z [...] 2020/02/16 15:46:53 backing up db=telegraf rp=default shard=1299 to /tmp/backup/telegraf.default.01299.00 since 0001-01-01T00:00:00Z 2020/02/16 15:46:54 backing up db=telegraf rp=default shard=1303 to /tmp/backup/telegraf.default.01303.00 since 0001-01-01T00:00:00Z 2020/02/16 15:46:56 backup complete: 2020/02/16 15:46:56 /tmp/backup/20200216T214204Z.meta 2020/02/16 15:46:56 /tmp/backup/20200216T214204Z.s1301.tar.gz [...] 2020/02/16 15:46:56 /tmp/backup/20200216T214204Z.s1303.tar.gz 2020/02/16 15:46:56 /tmp/backup/20200216T214204Z.manifest
Una vez que tenemos todo y el backup ha terminado, podremos copiar este backup hacía el nuevo servidor, un SCP es lo más sencillo:
scp -r /tmp/backup/* [email protected]:/tmp/backup The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established. ECDSA key fingerprint is SHA256:5CU0l1AL/LoCnrMsAq/LbE/3jYVKYxb+F0YkKEnxsPc. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.4' (ECDSA) to the list of known hosts. 20200216T214204Z.manifest 100% 37KB 36.7KB/s 00:00 20200216T214204Z.meta 100% 6986 6.8KB/s 00:00 20200216T214204Z.s1004.tar.gz 100% 35MB 35.4MB/s 00:01 20200216T214204Z.s1012.tar.gz 100% 20MB 19.8MB/s 00:00 20200216T214204Z.s1042.tar.gz 100% 37MB 37.4MB/s 00:00
Una vez que la copia ha terminado, ya podremos irnos al nuevo servidor de InfluxDB y continuar con los pasos.
Restaurar el Backup de InfluxDB Open-Source Edition
¡Muy importante! Es importante que no tengamos la base de datos de telegraf en el nuevo InfluxDB, ya que si no el proceso fallará, el comando para restaurar la información es muy sencillo, con un simple restore:
influxd restore -portable /tmp/backup
Podremos ver en la consola un paso a paso con todos los import de cada trozo del backup, tardará más o menos dependiendo del tamaño del backup:
2020/02/16 21:56:58 Meta info not found for shard 1302 on database _internal. Skipping shard file 20200216T214204Z.s1302.tar.gz 2020/02/16 21:56:58 Restoring shard 347 live from backup 20200216T214204Z.s347.tar.gz 2020/02/16 21:56:58 Restoring shard 280 live from backup 20200216T214204Z.s280.tar.gz 2020/02/16 21:56:58 Restoring shard 320 live from backup 20200216T214204Z.s320.tar.gz [...] 2020/02/16 21:59:11 Restoring shard 1004 live from backup 20200216T214204Z.s1004.tar.gz 2020/02/16 21:59:12 Restoring shard 1057 live from backup 20200216T214204Z.s1057.tar.gz
Una vez termina de importar todo, por defecto se omite la base de datos de _internal, podemos pasar al siguiente paso.
Comprobar que tenemos información de nuevo en Chronograf
Vuelta de nuevo a nuestro nuevo Chronograf, ya podremos ver que si nos vamos a la base de datos de telegraf que acabamos de importar, podemos encontrar la información que acabamos de importar desde el backup:
¡Felicidades! Ya hemos migrado todo el InfluxDB de un servidor a otro, con un pequeño downtime, pero sin duda no hay ningún paso realmente complicado.
Componentes adicionales a considerar en la migración
Si, como yo, tenéis también Grafana y Telegraf en la misma máquina, y estáis migrando todo, os recomiendo estar atentos a:
- Si tuvieráis configuraciones para las diferentes aplicaciones a monitorizar en el directorio /etc/telegraf/telegraf.d/ todo lo que haya dentro, moverlo.
- A estas alturas supongo que no estáis usando el fichero telegraf.conf para nada, ya que se suele sobre-escribir cada vez que hay updates, mejor no tocarlo.
- Si estuvieráis usando un certificado válido de SSL, tendréis que migrar todo el proceso usando los siguientes pasos:
- Antes de apagar la vieja máquina, os recomiendo exportar todos los Dashboards de Grafana, en formato .json, para poderlos importar en la nueva VM.
- En caso de que la IP y FQDN van a ser diferentes, todos los telegraf agents que tenemos tendrán que apuntar hacía el nuevo FQDN.
Una vez tengamos todo ya realizado, podremos apagar la vieja VM y cambiar la IP de la nueva para que reemplace a la anterior, etc.
Leave a Reply