ApsaraDB for MongoDB:ApsaraDB for MongoDBインスタンスの高ディスク使用量のトラブルシューティング

次の方法を使用して、ApsaraDB for MongoDBコンソールでシャードクラスターインスタンスのディスク使用率を表示できます。

• モニタリングチャートを使用した詳細分析

  インスタンスの [モニタリングデータ] ページで、ノードを選択し、ノードの [ディスク使用量 (バイト)] と [ディスク使用量 (%)] の値を表示します。

• コマンドの実行による詳細分析

  MongoDBが提供するdb.stats() およびdb.$collection_name.stats() コマンドを実行して、各ノードのディスク使用量を分析します。

セカンダリノードでdb.ru nCommand({compact:"collectionName"}) コマンドを実行し、プライマリ /セカンダリの切り替えを実行して、ビジネスへの影響を最小限に抑えます。 collectionNameパラメーターは、コレクション名を示します。 パラメーター値を実際のコレクション名に置き換えます。

compactコマンドを実行した後、既存のデータを格納するための新しいスペースはすぐには作成されません。 代わりに、既存のデータはフリースペースに連続的に移動されます。 しかしながら、空き領域は、既存のデータを格納するために再利用されない。 次のセクションでは、シナリオとソリューションについて説明します。

• compactコマンドを実行すると、コンパクト操作が成功したことを示すプロンプトが表示されます。 ただし、既存の空き領域は使用できません。 この場合、別のレプリカを作成することをお勧めします。

• MongoDB 3.4より前のバージョンでは、コンパクト操作はデータファイルに対してのみ有効になり、大量のデータが削除された後はインデックスファイルに対しては有効になりません。 この場合、データベースエンジンのバージョンをMongoDB 3.4以降にアップグレードすることを推奨します。 コンパクト操作がインデックスファイルに対して有効かどうかを確認するには、次のいずれかの操作を実行します。

  1. db.$table_name.stats().indexSizesコマンドを実行します。

  2. 物理インデックスファイルのサイズを表示します。

MongoDB 4.0より前のバージョンでは、ホスト上の開いているファイルのサイズが指定された上限に達すると、MongoDBログサーバー上のよりクリーンなスレッドが終了します。 その結果、ジャーナルログのサイズは無限に大きくなります。 次のコードブロックに似たコンテンツがインスタンスのランタイムログに表示される場合は、MongoDBのバージョンを4.0以降にアップグレードするか、mongodプロセスを再起動することで、一時的に問題を解決できます。 詳細については、「mongodbプロセスの実行中にエラーが発生した場合にログサーバースレッドが静かに終了する」をご参照ください。

2019-08-25T09:45:16.867 + 0800ネットワーク [thread1] Listener: accept() returns -1 Too many open files in system
2019-08-25T09:45:17.000 + 0800 I - [ftdc] アサーション: 13538: 開くことができませんでした [/proc/55692/stat] システムsrc/mongo/util/processinfo_linux.cppで開いているファイルが多すぎます74
2019-08-25T09:45:17.002 0800 W FTDC [ftdc] 「Location13538: フルタイムの診断データキャプチャサブシステムで [/proc/55692/stat] システム内の開いているファイルが多すぎる」のキャッチされない例外。 フルタイムの診断データ取得サブシステムをシャットダウンします。

上記のシナリオの問題を解決するには、次のコードに示すようにoplogsに対してコンパクト操作を実行します。

db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
ローカルを使用
db.ru nCommand({ compact: "oplog.rs", force: true }) 

シャードクラスタインスタンスでは、適切なシャーディングキーが重要です。 ほとんどの場合、ハッシュシャーディングまたはレンジドシャーディングが使用されます。 ディスクの負荷分散には、レンジドシャーディングよりもハッシュシャーディングの方が適しています。 ハッシュシャーディングは、組み込みのハッシュ関数を使用して、さまざまなキー値に基づいてデータをシャード間で均等に分散します。 レンジドシャーディングは、キー値の範囲に基づいてシャード間でデータを分散するため、データの分散が不均一になります。 データは、ポピュレートされたチャンクに分散される。 これにより、チャンクが配置されているディスクでのI/Oワークロードが高くなり、短期間のデータ分散が不均一になる可能性があります。

各シャードのチャンク数は基本的に同じです。 ただし、ほとんどのデータはいくつかのポピュレートされたチャンクにのみ格納されるため、データ分散が不均一になります。 インスタンスのランタイムログを表示するには、sh.status() コマンドを実行します。 アラート情報は、出力に表示され得る。 次のコードは、アラート情報の例を示しています。

2019-08-27T13:31:22.076 + 0800 W SHARDING [conn12681919] superHotItemPoolで検出された可能性のある低濃度キー。haodanku_all-キーは {batch: "201908260000"} です
2019-08-27T13:31:22.076 + 0800 W SHARDING [conn12681919] superHotItemPoolで検出された可能性のある低濃度キー。haodanku_all-キーは {batch: "201908260200"} です
2019-08-27T13:31:22.076 + 0800 W SHARDING [conn12681919] superHotItemPoolで検出された可能性のある低濃度キー。haodanku_all-キーは {batch: "201908260230" } 

上記のシナリオの問題を解決するには、次の操作を実行することを推奨します。

• 宛先インスタンスがデフォルトでシャードされていない場合は、データをインポートする前に宛先インスタンスのシャーディングポリシーを設定します。

• アンシャードデータベースの数が多く、データベースのデータ量が類似している場合は、ApsaraDB for MongoDBが提供するmovePrimaryコマンドを実行して、特定のデータベースを特定のシャードに移行します。

• データベースのデータ量が多すぎてシャードされていない場合は、データベースをシャードするか、データベースを個別のレプリカセットとして分割することをお勧めします。

• ディスク容量が十分な場合は、これらの問題を無視することを推奨します。