C'è stata una certa confusione sulla bonifica dello spazio in MongoDB e alcune pratiche raccomandate sono decisamente pericolose da fare in alcuni tipi di schieramento. Maggiori dettagli di seguito:
TL; DR repairDatabase tenta di recuperare i dati da una distribuzione autonoma di MongoDB che sta tentando di recuperare da un danneggiamento del disco. Se recupera spazio, è puramente un effetto collaterale . Il recupero dello spazio non dovrebbe mai essere la considerazione principale della corsa repairDatabase.
Ripristinare lo spazio in un nodo autonomo
WiredTiger: per un nodo autonomo con WiredTiger, l'esecuzione compactrilascerà spazio sul sistema operativo, con un avvertimento: il compactcomando su WiredTiger su MongoDB 3.0.x è stato interessato da questo errore: SERVER-21833 che è stato corretto in MongoDB 3.2.3. Prima di questa versione,compact su WiredTiger poteva fallire silenziosamente.
MMAPv1: a causa del modo in cui funziona MMAPv1, non esiste un metodo sicuro e supportato per recuperare spazio utilizzando il motore di archiviazione MMAPv1. compactin MMAPv1 deframmenterà i file di dati, rendendo potenzialmente più spazio disponibile per i nuovi documenti, ma non rilascerà spazio sul sistema operativo.
Si può essere in grado di eseguire repairDatabase, se si comprende appieno le conseguenze di questa potenzialmente pericolosa comando (vedi sotto), dal momento cherepairDatabase essenzialmente riscrive l'intero database scartando i documenti corrotti. Come effetto collaterale, questo creerà nuovi file di dati MMAPv1 senza alcuna frammentazione e rilascerà spazio sul sistema operativo.
Per un metodo meno avventuroso, in esecuzione mongodumpe mongorestorepotrebbe essere possibile anche in una distribuzione MMAPv1, a seconda delle dimensioni della distribuzione.
Ripristinare lo spazio in un set di repliche
Per le configurazioni dei set di repliche, il metodo migliore e più sicuro per recuperare spazio è eseguire una sincronizzazione iniziale , sia per WiredTiger che per MMAPv1.
Se è necessario recuperare spazio da tutti i nodi del set, è possibile eseguire una sincronizzazione iniziale continua. Ossia, esegui la sincronizzazione iniziale su ciascuno dei secondari, prima di abbandonare il primario ed eseguire la sincronizzazione iniziale su di esso. Il metodo di sincronizzazione iniziale a rotazione è il metodo più sicuro per eseguire la manutenzione del set di repliche e non comporta alcun downtime come bonus.
La fattibilità di eseguire una sincronizzazione iniziale continua dipende anche dalle dimensioni della distribuzione. Per distribuzioni estremamente grandi, potrebbe non essere possibile eseguire una sincronizzazione iniziale, quindi le opzioni sono leggermente più limitate. Se si utilizza WiredTiger, è possibile estrarre un secondario dall'insieme, avviarlo come autonomo, eseguirlo compacte ricollegarlo all'insieme.
per quanto riguarda repairDatabase
Non eseguire repairDatabasesui nodi del set di repliche . Questo è molto pericoloso, come menzionato nella pagina di riparazione del database e descritto in maggiori dettagli di seguito.
Il nome repairDatabaseè un po 'fuorviante, poiché il comando non tenta di riparare nulla. Il comando doveva essere utilizzato in caso di corruzione del disco su un nodo autonomo , che potrebbe portare a documenti corrotti.
Il repairDatabasecomando potrebbe essere descritto più accuratamente come "database di salvataggio". Cioè, ricrea i database scartando i documenti corrotti nel tentativo di portare il database in uno stato in cui è possibile avviarlo e recuperare il documento intatto da esso.
Nelle distribuzioni MMAPv1, questa ricostruzione dei file di database rilascia spazio sul sistema operativo come effetto collaterale . Rilasciare spazio sul sistema operativo non è mai stato lo scopo.
Conseguenze di repairDatabaseun set di repliche
In un set di repliche, MongoDB prevede che tutti i nodi del set contengano dati identici. Se si esegue repairDatabasesu un nodo del set di repliche, è possibile che il nodo contenga corruzione non rilevata e repairDatabaserimuoverà debitamente i documenti corrotti.
Com'era prevedibile, questo rende quel nodo contenente un set di dati diverso dal resto dell'insieme. Se un aggiornamento dovesse colpire quel singolo documento, l'intero set potrebbe andare in crash.
A peggiorare le cose, è del tutto possibile che questa situazione possa rimanere inattiva a lungo, solo per colpire improvvisamente senza una ragione apparente.
