6

ここに投稿する返信がないので、mongodb google group でこの質問に回答しました。

単一ノードの mongo (バージョン 2.0.1) インスタンスがあります。mongo はディスク領域を OS に戻さず、それ自体を使用しようとするため、毎日のアーカイブの後でもディスク領域が不足しています。現在、セットアップは非常にまばらになり、約 50% のスペースがアイドル状態になっています。データ + インデックス サイズが約 1170 GB であるのに対し、ストレージ サイズは約 2158 GB、ファイル サイズは約 2368 GB であることがわかります。 

db.stats()    
{  
    "db" : "default",            
    "collections" : 106,  
    "objects" : 553988389,  
    "avgObjSize" : 2094.1392962010254,  
    "dataSize" : NumberLong("1160128855044"),  
    "storageSize" : NumberLong("2315777236208"),  
    "numExtents" : 1487,  
    "indexes" : 107,  
    "indexSize" : 97914435136,  
    "fileSize" : NumberLong("2543459500032"),  
    "nsSizeMB" : 16,  
    "ok" : 1  
}

スペースを再利用したいのですが、これはミッション クリティカルなシステムではないため (丸太のゴミ捨て場のようなものです)、ダウンタイムが発生する可能性があります。物理データセンターにいるため、レプリカ セットの作成に費用をかけたくないため、データベースを修復するためだけに追加のディスクを接続しないことを好みます。
理解したいこと:- -
データベースの修復に必要な空きディスク容量-データベースの
修復後に回復できるディスク領域の量 -データベースの
修復にかかる時間
-データベースの修復が引き続き行われる場合は、それを強制終了してデータベースを再起動しても安全ですか。

私たちのデータの大部分は単一のコレクションにあるため、データベースを修復するよりもコンパクトなコレクションの方が優れているかどうか.

4

1 に答える 1

3

まず、2.0.1からアップグレードすることをお勧めします。2.2.2でない場合は、少なくとも2.0.7まで。修復には2倍のファイルサイズが必要です。最終的には、ファイルサイズとしてのデータサイズよりもわずかに大きくなるはずです。所要時間は、システムリソースとシステムのビジー状態によって異なります。Compactは、ディスク上のスペースを解放しません。データファイル内でデフラグするだけです。

2.2.xでは、 collModを使用できます

ファイルの断片化を減らすためにusePowerOf2Sizesを設定するコマンド。たとえば、800バイトのドキュメントを挿入すると1024バイトが割り当てられます。そのドキュメントを削除し、900バイトのドキュメントを挿入します。これで1024スペースを再利用できます。これがなければ、おそらく850バイトしか割り当てられず、900バイトのドキュメントに新しい空き領域が割り当てられていたでしょう。

repairDatabaseを強制終了しても問題ありません-ファイルは新しい場所にコピーされ、defraggされてから完了時にコピーされますが、テストして確認する必要があります:)

于 2013-01-23T11:09:18.677 に答える