Ha habido una considerable confusión sobre la recuperación de espacio en MongoDB, y algunas prácticas recomendadas son francamente peligrosas en ciertos tipos de implementación. Más detalles a continuación:
TL; DR repairDatabase intenta recuperar datos de una implementación independiente de MongoDB que está intentando recuperarse de un daño en el disco. Si recupera espacio, es puramente un efecto secundario . La recuperación del espacio nunca debería ser la consideración principal de la ejecución repairDatabase.
Recuperar espacio en un nodo independiente
WiredTiger: para un nodo independiente con WiredTiger, la ejecución compactliberará espacio para el sistema operativo, con una advertencia: el compactcomando en WiredTiger en MongoDB 3.0.x se vio afectado por este error: SERVER-21833 que se corrigió en MongoDB 3.2.3. Antes de esta versión, compacten WiredTiger podía fallar silenciosamente.
MMAPv1: debido a la forma en que funciona MMAPv1, no existe un método seguro y compatible para recuperar espacio utilizando el motor de almacenamiento MMAPv1. compacten MMAPv1 desfragmentará los archivos de datos, potencialmente haciendo más espacio disponible para nuevos documentos, pero no liberará espacio de nuevo al sistema operativo.
Es posible que pueda ejecutar repairDatabasesi comprende completamente las consecuencias de este comando potencialmente peligroso (ver más abajo), ya que repairDatabaseesencialmente reescribe toda la base de datos descartando documentos corruptos. Como efecto secundario, esto creará nuevos archivos de datos MMAPv1 sin ninguna fragmentación y liberará espacio al sistema operativo.
Para un método menos aventurero, ejecutar mongodumpy también mongorestorepuede ser posible en una implementación MMAPv1, sujeto al tamaño de su implementación.
Recuperar espacio en un conjunto de réplicas
Para configuraciones de conjunto de réplica, el mejor y más seguro método para recuperar espacio es realizar una sincronización inicial , tanto para WiredTiger como para MMAPv1.
Si necesita recuperar espacio de todos los nodos del conjunto, puede realizar una sincronización inicial continua. Es decir, realice la sincronización inicial en cada una de las secundarias, antes de finalmente bajar la primaria y realizar la sincronización inicial en ella. El método de sincronización inicial progresiva es el método más seguro para realizar el mantenimiento del conjunto de réplicas, y tampoco implica un tiempo de inactividad como beneficio adicional.
Tenga en cuenta que la viabilidad de realizar una sincronización inicial continua también depende del tamaño de su implementación. Para implementaciones extremadamente grandes, puede que no sea factible hacer una sincronización inicial y, por lo tanto, sus opciones son algo más limitadas. Si se usa WiredTiger, es posible que pueda quitar un secundario del conjunto, iniciarlo de forma independiente, ejecutarlo compacty volver a unirlo al conjunto.
Respecto a repairDatabase
No ejecute repairDatabaseen nodos de conjunto de réplica . Esto es muy peligroso, como se menciona en la página RepairDatabase y se describe con más detalles a continuación.
El nombre repairDatabasees un poco engañoso, ya que el comando no intenta reparar nada. El comando estaba destinado a utilizarse cuando hay daños en el disco en un nodo independiente , lo que podría conducir a documentos corruptos.
El repairDatabasecomando podría describirse con mayor precisión como "base de datos de recuperación". Es decir, recrea las bases de datos descartando documentos corruptos en un intento de llevar la base de datos a un estado en el que pueda iniciarla y recuperar el documento intacto.
En las implementaciones de MMAPv1, esta reconstrucción de los archivos de la base de datos libera espacio al sistema operativo como efecto secundario . Liberar espacio para el sistema operativo nunca fue el propósito.
Consecuencias de repairDatabaseen un conjunto de réplicas
En un conjunto de réplica, MongoDB espera que todos los nodos del conjunto contengan datos idénticos. Si se ejecuta repairDatabaseen un nodo de conjunto de réplicas, existe la posibilidad de que el nodo contenga corrupción no detectada y repairDatabaseelimine debidamente los documentos corruptos por usted.
Como era de esperar, esto hace que ese nodo contenga un conjunto de datos diferente del resto del conjunto. Si una actualización llega a ese único documento, todo el conjunto podría fallar.
Para empeorar las cosas, es completamente posible que esta situación permanezca latente durante mucho tiempo, solo para golpear repentinamente sin razón aparente.
