MongoDBデプロイメントにおけるディスク容量の管理と解放

MongoDBのディスク容量問題は通常、2つの形で現れます：ファイルシステムがほぼ満杯になっているか、データを削除した後でもMongoDBが大きく見える場合です。後者のケースは多くのチームを驚かせます。なぜならWiredTigerは解放された領域を内部的に再利用でき、すぐにオペレーティングシステムに返さないからです。

目標は、実際の成長、再利用可能な内部空き領域、肥大化したインデックス、およびメンテナンスウィンドウを必要とする断片化を区別することです。

ホストレベルでのディスク使用量の確認

MongoDBのdbPathを含むファイルシステムから始めます。そのボリュームが満杯になると、MongoDBは安全に書き込みを続けられません。

df -h /var/lib/mongodb

また、どのディレクトリが成長しているかも確認します：

du -sh /var/lib/mongodb/* | sort -h

実際のdbPathを使用してください。/var/lib/mongodbはLinuxパッケージでは一般的ですが、普遍的なものではありません。

MongoDBストレージメトリクスの確認

mongosh内で、論理データサイズと割り当てられたストレージサイズを比較します。

use myDatabase
db.stats()

有用なフィールドには以下が含まれます：

• dataSize：ドキュメントデータの論理サイズ。
• storageSize：コレクションデータに割り当てられた領域。
• indexSize：インデックスが使用する領域。

特定のコレクションの場合：

db.orders.stats({ scale: 1024 * 1024 })

size、storageSize、totalIndexSizeを確認します。storageSizeがsizeよりはるかに大きい場合、コレクションには更新や削除による再利用可能な内部領域がある可能性があります。totalIndexSizeが大きい場合、インデックスがディスク使用量を削減する最も速い方法かもしれません。

MongoDBディスク増加の一般的な原因

高い削除と更新のチャーンは、WiredTigerファイル内に内部空き領域を残す可能性があります。MongoDBは将来の書き込みのためにその領域を再利用することがよくありますが、オペレーティングシステムは依然としてファイルを大きく表示する場合があります。

インデックスもディスクの大部分を消費する可能性があります。複合インデックス、テキストインデックス、ワイルドカードインデックス、重複インデックスは急速に蓄積されます。

保持期間のギャップももう一つの一般的な原因です。ログ、セッション、イベント、監査コレクションは、古いドキュメントをアーカイブまたは期限切れにしない限り、永久に成長し続けます。

将来の成長を抑える安全な方法

最善のディスク修正は通常、無制限の成長を防ぐことです。

時間ベースのデータには、TTLインデックスを作成します：

db.logEvents.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400 }
)

TTL削除はバックグラウンドモニターによって処理され、秒単位で即座に行われるわけではありません。それでも、正確な削除タイミングが重要でないログ、セッション、一時的なイベントには適しています。

何かを削除する前にインデックスを確認します：

db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])

$indexStatsは、プロセスが開始されてからインデックスが使用されたかどうかを示すことができます。これは手がかりとして扱い、証明としては扱わないでください。月次レポートのインデックスは、静かな週には未使用に見えるかもしれません。

確認済みの未使用インデックスを名前で削除します：

db.orders.dropIndex('customerId_1_createdAt_-1')

既存ファイルからの領域の再利用

通常、ドキュメントを削除してもディスク上のWiredTigerファイルは縮小しません。領域をファイルシステムに戻すには、再書き込みまたはコンパクション戦略が必要です。

compactを慎重に使用する

compactはコレクションとインデックスデータを再書き込みしてディスク使用量を削減できます。これはリソース集約的であり、MongoDBのバージョンとデプロイメントによっては、影響を受けるコレクションに対する操作をブロックする可能性があります。

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

メンテナンスウィンドウ中に実行し、最初にテストし、正確なMongoDBバージョンのドキュメントを読んでください。レプリカセットでは、多くのチームが一度に1つのセカンダリをコンパクションし、追いつかせてから、必要に応じてメンバーをステップダウンまたはローテーションします。

深刻な断片化に対するダンプとリストア

ひどく断片化したデータの場合、ダンプアンドリストアはコレクションファイルをクリーンに再構築します。これをその場で行うと中断が発生するため、バックアップ、ダウンタイム、またはレプリカベースの移行を計画してください。

mongodump --db myDatabase --collection orders --out /backup/mongo-dump

ダンプを確認し、切り替えを計画した後、ターゲット環境にリストアします：

mongorestore --db myDatabase --collection orders \
  /backup/mongo-dump/myDatabase/orders.bson

確認済みのバックアップとロールバック計画ができるまで、本番データを削除しないでください。

やってはいけないこと

WiredTiger、ジャーナル、またはコレクションファイルをファイルシステムから手動で削除しないでください。データベースが破損する可能性があります。

duとMongoDBの論理サイズが一致するべきだと想定しないでください。圧縮、インデックス、内部空き領域、ファイルシステムの動作がすべて数値に影響します。

MMAPv1スタイルの事前割り当てに関する古いアドバイスには注意してください。現代のMongoDBデプロイメントは通常WiredTigerを使用しており、そのストレージ動作は異なります。

実践的なポイント

MongoDBのディスク使用量がおかしいと思ったら、最初にホストを測定し、次にデータベース、コレクション、インデックスを測定します。TTLインデックスとアーカイブを使用して成長を遅らせます。確認済みの不要なインデックスのみを削除します。実際のファイルシステム領域の再利用には、削除がすぐにファイルを縮小することを期待するのではなく、compactまたはダンプアンドリストアワークフローを計画します。