2012-07-23 19 views
11

Quiero reducir el tamaño de los archivos de datos recuperando el espacio eliminado, pero no puedo ejecutar db.repairDatabase(), porque el espacio libre en el disco no es suficiente.Cómo reclamar espacio eliminado sin `db.repairDatabase()`?

+0

¿Puede mover sus archivos a otro disco/máquina y hacer esto? Creo que este es uno de los puntos dolorosos en el conjunto de herramientas de mongo existente: qué hacer cuando se queda sin espacio en disco. –

Respuesta

11

La respuesta original a esta pregunta es aquí: Reducing MongoDB database file size

realmente no hay nada fuera de repair que recuperar espacio. El compact debería permitirle ir mucho más tiempo en el espacio existente. De lo contrario, tendrá que migrar a una unidad más grande.

Una forma de hacerlo es utilizar un secundario fuera de línea de su conjunto de réplicas. Esto debería darle una ventana completa de mantenimiento para migrar, reparar, retroceder y volver a subir.

Si no está ejecutando un conjunto de réplicas, es hora de hacer eso.

+1

¿Esta respuesta sigue siendo válida a partir de ahora? –

+1

Desde que se publicó esta respuesta, MongoDB ha agregado WiredTiger para almacenar archivos. WiredTiger es mucho más eficiente en términos de uso de disco, sin embargo, no puede implementarlo "en el lugar". Por lo tanto, las respuestas anteriores aún se deben aplicar. –

11

Puede ejecutar el comando compact en una sola colección, o una por una en todas las colecciones que desee contraer.

http://www.mongodb.org/display/DOCS/Compact+Command

db.runCommand({ compact : 'mycollectionname' }) 

Como se señaló en los comentarios, yo estaba equivocada, compacto en realidad no recuperar espacio en el disco, sólo se desfragmenta y reconstruye los índices de recogida.

En su lugar, podría utilizar la opción "--repairpath" si tiene otra unidad disponible que tiene espacio libre disponible.

Por ejemplo:

mongod --dbpath /data/db --repair --repairpath /data/db0 

se muestra aquí: http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/

+0

Esto realmente no reclama espacio en el disco, estoy bastante seguro. –

+0

Solo un aviso, de acuerdo con los documentos, '--repairpath' es," solo está disponible para la instancia de mongod que usa el motor de almacenamiento MMAPv1 ". https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption--repairpath – Grinn

1

Hay otra opción, si está utilizando un conjunto de réplicas, pero con muchas advertencias. Puede conmutar por error a otro miembro del conjunto, luego eliminar los archivos en el primario anterior y hacer una resincronización completa. Una resincronización completa reescribe los archivos desde cero de forma similar a una reparación, pero también tendrá que volver a generar los índices. Esto no debe hacerse a la ligera.

Si sigue este camino, mi recomendación sería tener un conjunto de réplicas de 3 miembros antes de hacer esto para la recuperación de espacio en disco, de modo que en cualquier momento cuando un miembro esté sincronizando desde cero tenga 2 miembros completamente operativos.

Si no tiene un conjunto de réplicas, le recomiendo que cree una, con dos secundarias. Cuando los sincronices inicialmente, estarás creando una buena versión sin fragmentar y sin relleno de tus datos. Más aquí:

http://www.mongodb.org/display/DOCS/Replica+Set+Configuration

11

Puede que también haga un mongodump manual y mongorestore. Eso es básicamente lo mismo que reparaDatabase. De esta forma, puede volcarlo y restaurarlo a/desde una máquina diferente con suficiente espacio en disco.

+0

+1 puede escribir una secuencia de comandos para hacer un mongodump/mongorestore en cada nodo –

+7

ESTO. Asegúrese de colocar el db primero antes de restaurarlo, para reclamar el espacio. Por supuesto, esta opción significa un poco de tiempo de inactividad, ¡pero para eso es 3AM! – CommaToast

4

Si está ejecutando un conjunto de réplicas, querrá emitir una resincronización en cada uno de sus secundarios, uno a la vez. Una vez que esto se haya completado, reduzca su primario y vuelva a sincronizar el secundario recientemente asignado.

Para volver a sincronizar, detenga su instancia de mongod, elimine los locales e inicie la copia de seguridad del proceso. Mire los registros para asegurarse de que todo vuelva a comenzar correctamente y se haya iniciado la resincronización.

Si tiene muchos datos/índices, asegúrese de que su oplog sea lo suficientemente grande, de lo contrario, es probable que quede obsoleto.

Cuestiones relacionadas