Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

En el ejemplo actual, se describe el procedimiento para mantener el histórico del último año, por lo cual el equipo de Opmantek LATAM recomienda realizar la compactación de la base de datos a partir de la fecha que se indica en los siguientes pasos.

Proceso

Nota: no es necesaria la detención de los demonios del servidor, este proceso puede aplicarse directamente en el servidor deseado.

1. Para este ejemplo, se purgan las colecciones de mongo "events", "actionlog" y "rawlogs", removiendo todo lo anterior a la fecha del miércoles 1 de enero de 2020 (1579651200 en formato Epoch). Esta fecha debe acordarse con cada cliente y se recomienda utilizar la página web https://www.epochconverter.com/ para poder realizar la conversión.

Se ejecutan los siguientes 4 comandos, uno a uno:

mongo -u opUserRW -p op42flow42 nmisng

> use opevents

> db.getCollection('opeventsevents').deleteManyremove({time: {$lt: 1579651200}})

> db.getCollection('actionlog').deleteManyremove({time: {$lt: 1579651200}})

> db.getCollection('rawlogs').deleteManyremove({time: {$lt: 1579651200}})

...

2. A continuación, se compactan cada una de las colecciones purgadas para liberar el espacio en disco, mediante la ejecución de los siguientes comandos, uno por a uno:

mongo -u opUserRW -p op42flow42 nmisng

> use opevents

> db.runCommand({compact: 'opeventsevents'}) no funciona

> db.runCommand({compact: 'rawlogs'}) no funciona

> db.runCommand({compact: 'actionlog'}) no funciona


3. Al final, se logra la reducción de /data a 70%:


Base de datos correcta: copia y restauración

Importante: Este proceso aplica cuando la base de datos funciona de manera correcta y solo se desea realizar una copia para restaurarla posteriormente, ya sea en el mismo servidor o en otro.

El procedimiento referido en este punto es recomendado cuando se desea realizar una copia de la base de datos y una restauración.

Proceso

Ejecutar el siguiente comando para generar un mongodump, lo cual creará una carpeta que contendrá las bases de datos del servidor:

Code Block
mongodump -u=opUserRW -p=op42flow42 --out=/data/mongodump


Borrar el contenido de la carpeta de mongo:

Code Block
cd /data/mongo o cd /var/lib/mongo #según aplique
rm -rf *


Ejecutar el setup de mongo para que se genere nuevamente la base de datos (este script debe activar el demonio mongod):

Code Block
/usr/local/omk/bin/setup_mongodb.pl


Ejecutar el siguiente comando para restaurar la base de datos, lo cual va a restaurar las bases de datos que se generaron con en el primer comando:

Code Block
mongorestore -u=opUserRW -p=op42flow42 /data/mongodump

Base de datos corrupta: procedimiento para restauración

Importante: Cuando la base de datos se corrompe no es posible recuperar los datos y únicamente es posible reiniciarla desde cero.

Advertencia: si se realiza este procedimiento, se creará una nueva base de datos y todo el histórico del servidor se perderá.

El procedimiento referido en este punto es recomendado cuando mongod no pueda iniciarse de manera correcta, lo cual puede deberse a una corrupción de la base de datos. Esto está provocando que NMIS y sus módulos funcionen de manera incorrecta.

Advertencia: si se realiza este procedimiento, se creará una nueva base de datos y todo el histórico del servidor se perderá.

Proceso

Detener nmis9d y mongod.

Code Block
[root@noc ~]# service nmis9d stop
[root@noc ~]# service mongod stop

...

Situarse en la carpeta de mongo y eliminar todo su contenido:

Code Block
cd /data/mongo o cd /var/lib/mongo #según aplique
rm -rf *


Eliminar los archivos .lock y .sock de mongo (si es que existen):

Code Block
rm /data/mongodb/mongod.lock o /var/lib/mongo/mongod.lock #según aplique
rm /tmp/mongodb-27017.sock

...

El procedimiento referido en este punto es recomendado para cuando mongod utiliza demasiados recursos del servidor, como puede verse en los siguientes ejemplos:

Proceso

Ejecutar los siguientes comandos, uno a uno:

...