ディスク使用率は、ApsaraDB for MongoDB インスタンスを監視するための重要なメトリックです。インスタンスのディスク使用率が 100% に達すると、インスタンスは使用できなくなります。このトピックでは、ディスク使用状況の詳細を表示し、インスタンスのディスク使用率が高い問題のトラブルシューティングを行う方法について説明します。
背景情報
インスタンスのディスク使用率が 80% を超えた場合は、インスタンスのディスク使用量を削減するか、ストレージ容量を拡張して、ディスク使用率が 100% に達しないようにすることができます。
ストレージ使用状況の表示
レプリカセットインスタンス
ApsaraDB for MongoDB コンソールで、次のいずれかの方法を使用して、レプリカセットインスタンスのディスク使用状況を表示できます。
概要
[基本情報] ページの [仕様情報] セクションで、インスタンスの [ディスク容量] と [使用率] 情報を表示します。
モニタリングチャートを使用した詳細分析
左側のナビゲーションウィンドウで、[モニタリングデータ] をクリックします。表示されるページで、ノードを指定し、ノードの [ディスク使用量（バイト）] と [ディスク使用量（%）] の値を表示します。
レプリカセットインスタンスは、読み取りおよび書き込み操作をサポートするプライマリノード、1 つ以上の高可用性セカンダリノード、非表示ノード、および 1 つ以上のオプションの読み取り専用ノードで構成されます。ノードのディスクはデータとログによって使用され、ディスクのストレージ容量は次の式に基づいて計算できます。ins_size = data_size + log_size。ここで、
data_size：collection で始まる名前の物理データファイル、index で始まる名前の物理インデックスファイル、および WiredTiger.wt などの一部の物理メタデータファイルなどのデータファイルによって使用されるディスク容量。データファイルには、ローカルデータベースに格納されているデータは含まれません。
log_size：ローカルデータベース、MongoDB 実行ログ、および一部の監査ログの物理サイズ。
詳細分析
ディスク使用状況の詳細を表示するには、次の方法を使用できます。
ApsaraDB for MongoDB によって提供される
db.stats()コマンドとdb.$collection_name.stats()コマンドを実行します。を選択し、[ストレージ分析] ページで詳細を表示します。
[ストレージ分析] ページでは、次の項目を表示できます。
データベースとコレクションのディスク使用量の概要、1 日あたりの平均増加量、および予測されるストレージの利用可能日数
異常なデータベースとコレクションのディスク使用量
特定のビジネスコレクションのディスク使用量の詳細は、インデックスファイルとデータファイルによって使用されるディスク容量、圧縮率、平均行サイズなどを含みます。
シャードクラスターインスタンス
ApsaraDB for MongoDB コンソールで、次のいずれかの方法を使用して、シャードクラスターインスタンスのディスク使用状況を表示できます。
モニタリングチャートを使用した詳細分析
インスタンスの [モニタリングデータ] ページで、ノードを選択し、ノードの [ディスク使用量（バイト）] と [ディスク使用量（%）] の値を表示します。
コマンドを実行して詳細分析を行う
ApsaraDB for MongoDB によって提供される
db.stats()コマンドとdb.$collection_name.stats()コマンドを実行して、各ノードのディスク使用状況を分析します。
compact コマンドによって引き起こされる大量のデータボリュームのトラブルシューティング
compact 中のインスタンスへの影響
compact コマンドの実行時間は、コレクションのデータボリュームに関連しています。データボリュームが大きい場合、compact コマンドは長時間実行されます。そのため、compact コマンドはオフピーク時に実行することをお勧めします。
compact 操作
ビジネスへの影響を最小限に抑えるために、セカンダリノードで db.runCommand({compact:"collectionName"}) コマンドを実行してから、プライマリ/セカンダリスイッチオーバーを実行します。collectionName パラメーターはコレクション名を示します。パラメーター値を実際のコレクション名に置き換えます。
compact コマンドの詳細については、「インスタンスのディスクをデフラグしてディスク使用率を高める」をご参照ください。
大量のログデータによって引き起こされる高い容量使用率のトラブルシューティング
多数のジャーナルログにより、プライマリノードとセカンダリノードで使用される容量の差が大きい
MongoDB 4.0 より前のバージョンでは、ホスト上の開いているファイルのサイズが指定された上限に達すると、MongoDB ログサーバーのクリーナースレッドが終了します。その結果、ジャーナルログのサイズが無限に増加します。インスタンスの実行時ログに次のコードブロックに類似したコンテンツが表示される場合は、MongoDB のバージョンを 4.0 以降にアップグレードするか、mongod プロセスを再起動することで、一時的に問題を解決できます。詳細については、「log-server thread exit quietly on error while the mongodb process still running」をご参照ください。
2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.セカンダリノードの遅延と増分バックアップにより、セカンダリノードのログ容量の使用量が継続的に増加する可能性がある
プライマリノードとセカンダリノード間の同期中に遅延が発生した場合、oplog の使用可能容量は構成ファイルで定義された固定コレクションサイズによって制限されません。理論的には、使用可能な容量は、申請したディスク容量の 20% に達する可能性があります。ただし、セカンダリノードの遅延が通常のレベルに低下した後、oplog によって使用される物理容量は解放されません。
非表示ノードでインスタンスの物理バックアップを実行すると、多数のチェックポイントが大量のデータを生成し、大量のログ容量を占有します。
上記のシナリオの問題を解決するには、次のコードに示すように、oplog で compact 操作を実行します。
compact 操作中は、すべての書き込み操作がブロックされます。
db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
use local
db.runCommand({ compact: "oplog.rs", force: true })不適切なシャーディングによって引き起こされる不均一なデータ分散のトラブルシューティング
シャーディングキータイプの選択が不適切なため、データが不均一に分散される
シャードクラスターインスタンスでは、シャーディングキータイプを選択することが重要です。ほとんどの場合、ハッシュシャーディングまたはレンジシャーディングが使用されます。ディスクの負荷分散には、レンジシャーディングよりもハッシュシャーディングの方が適しています。ハッシュシャーディングは、組み込みのハッシュ関数を使用して、さまざまなキー値に基づいてシャード間でデータを均等に分散します。レンジシャーディングは、キー値の範囲に基づいてシャード間でデータを分散するため、データの分散が不均一になります。データは、設定されたチャンクに分散されます。これにより、チャンクが配置されているディスクで I/O ワークロードが高くなり、短期間でデータ分散が不均一になる可能性があります。
シャーディングキータイプの詳細については、「sharding-shard-key」、「hashed-sharding」、および「ranged-sharding」を参照してください。
シャーディングキーフィールドの選択が不適切なため、データが不均一に分散される
各シャードのチャンク数は本質的に同じです。ただし、ほとんどのデータは、設定されたいくつかのチャンクにのみ格納されるため、データ分散が不均一になります。インスタンスの実行時ログを表示するには、sh.status() コマンドを実行します。出力にアラート情報が表示される場合があります。次のコードは、アラート情報の例を示しています。
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" }
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" }
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }MongoDB バランサーは、データボリュームに関係なく、各シャードのチャンク数を監視します。この場合、各シャードのチャンク数はバランスが取れていますが、データが大きく歪んでいる可能性があります。チャンクでは、シャーディングキーはほぼ同じです。チャンクサイズが 64 MB に達すると、空のチャンクが作成されます。このようにして、チャンク数が増加し、チャンクの移行が完了します。ただし、移行されたチャンクは空のチャンクです。その結果、シャードのチャンク数は同じになりますが、データサイズは大きく異なる場合があります。この場合、識別度の高い適切な列を使用して、シャーディングキーを再設計する必要があります。
チャンクの分割方法の詳細については、「チャンクを使用したデータパーティショニング」および「シャードクラスター内のチャンクの分割」を参照してください。
シャーディングされていないデータベースからジャンボシャードが発生する
ApsaraDB for MongoDB シャードクラスターインスタンスの一部のデータベースをシャーディングできます。この場合、シャーディングされていないデータベースのデータは 1 つのシャードにのみ格納されます。データベースに大量のデータがある場合、データを格納するシャードは他のシャードよりも大量のデータを持ちます。
別のケースでは、データがソース ApsaraDB for MongoDB インスタンスから宛先 ApsaraDB for MongoDB インスタンスに論理的にインポートされると、宛先 ApsaraDB for MongoDB インスタンスはシャーディングされない場合があります。
上記のシナリオの問題を解決するには、次の操作を実行することをお勧めします。
宛先シャードクラスターインスタンスへのデータインポートが初期化されている場合は、データインポートの前に宛先インスタンスをシャーディングすることをお勧めします。
シャーディングされていないデータベースが多数あり、データベースのデータボリュームが類似している場合は、ApsaraDB for MongoDB によって提供される
movePrimaryコマンドを実行して、特定のデータベースを特定のシャードに移行することをお勧めします。データベースのデータ量が過剰に多く、シャーディングされていない場合は、データベースをシャーディングするか、データベースを個別のレプリカセットとして分割することをお勧めします。
ディスク容量が十分な場合は、これらの問題を無視することをお勧めします。
多数の moveChunk 操作によってシャードのディスク使用量が不均一になる
moveChunk 操作は、データが宛先シャードに書き込まれた後にソースデータを削除するために使用されます。デフォルトでは、削除操作では容量は解放されません。wiredTiger エンジンを実行するインスタンスでは、各コレクションにデータファイルとインデックスファイルがあります。ファイルが削除されない場合、占有されている容量は解放されません。ほとんどの場合、この問題は、インスタンスが一定期間実行された後にインスタンスにシャーディングが実装されるために発生します。
原則として、moveChunk 操作は、大規模な削除操作と同様に、断片化を引き起こします。したがって、moveChunk または削除操作を必要とするドキュメントがシャードで大量に生成される場合は、シャードで compact 操作を実行してディスクをデフラグできます。通常のケースでは、compact 操作後にデータが再編成され、ディスクがデフラグされます。
moveChunk の詳細については、「シャードクラスター内の範囲の移行」および「シャードクラスターバランサーの管理」を参照してください。