小さな AWS Linux インスタンスで Mongo を実行しています。今朝、システムがシャットダウンし、ディスクがいっぱいになったためにデータベース ロックが失敗したというログに多くのエラーが記録されました。
なぜ/何がいっぱいなのかを知るにはどうすればよいですか? 小規模な AWS インスタンスでは 160G を利用できるはずだと思っていましたか? mongo /data ディレクトリを調べると、5.5G が使用されていることがわかります。
Mongo がディスクを大量に消費する可能性があることはわかっています。私のデータ (生) は、約 150 ～ 200 MB の JSON です。
おっしゃるとおり、小さいインスタンスは一時ディスクをローカルに持っていますが、ルート / ではなく /media/ephemeral0 のような場所にマウントされています。デフォルトでは、EBS ルート ボリュームは / にマウントされ、MongoDB のデフォルト データ ディレクトリは /data です。つまり、MongoDB はエフェメラル ディスクではなく、EBS ルート ボリュームに配置されます。
さらに、インスタンスが終了するとエフェメラル ストレージが失われるため、データ損失の影響に慣れていない限り、通常は使用をお勧めしません。
ディスクがいっぱいになっている可能性があります。
160 GB という数値は、明示的に有効にした場合にのみ有効になるインスタンス ストレージを指します。デフォルトで有効になっていない理由は、永続的ではないためです。このストレージはホストに接続されているため、インスタンスを停止したり、何らかの理由でホストに障害が発生したりすると、そこに含まれているものはすべて失われます。
使用しているストレージは EBS ボリュームです。AWS は SAN ボリュームに相当します。デフォルトでは、ほとんどの AMI がこのボリュームを約 8 ～ 10 GB で作成します。そのサイズは、ボリュームあたり最大 1 TB まで増やすことができます。
現在の状況を修正するには、ダウンタイムが必要です。より多くのスペースで構成された新しいインスタンスにインポートすることができます。それ以外の場合は、現在のボリュームのスナップショットを作成し、そのスナップショットを使用して新しいより大きなボリュームを作成できます。すべてのスペースを利用するには、パーティションのサイズを変更する必要があります。