ApsaraDB for MongoDB:MongoDB インスタンスのディスク領域使用率が高い問題

シャードクラスターアーキテクチャ

ApsaraDB for MongoDB インスタンスがシャードクラスターアーキテクチャを使用している場合、ApsaraDB for MongoDB コンソール にログインし、以下の方法で領域使用状況を確認できます。

• モニタリングチャート分析

  Monitoring Information ページで、対象ノードを選択して、その ディスク使用率 (バイト) および ディスク使用率 (%) を表示します。

• 詳細分析

  MongoDB のネイティブコマンド db.stats() および db.$collection_name.stats() を使用して、各ノードの領域使用状況を順次分析します。

compact メソッド

ビジネスへの影響を最小限に抑えるため、まずセカンダリノードで db.runCommand({compact:"collectionName"}) コマンドを実行し、その後プライマリ/セカンダリ スイッチオーバーを実施します。collectionName は、ご利用のコレクション名に置き換えてください。

compact コマンドの使用方法の詳細については、「ディスクの最適化によるディスク使用率の改善」をご参照ください。

ジャーナルログの肥大化による領域ギャップ

ApsaraDB for MongoDB 4.0 より前のバージョンでは、ホストマシン上のオープンファイル数が上限に達すると、内部ログサーバーのクリーンアップスレッドが中断され、ジャーナルログが無制限に増加します。MongoDB ランタイムログに以下のようなログエントリが表示される場合は、カーネルを ApsaraDB for 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.

不適切なシャードキーの種類

シャードクラスターでは、シャードキーの種類の選択が重要です。主な種類はハッシュシャーディングとレンジシャーディングです。ディスクのバランスを取る観点では、ハッシュシャーディングがレンジシャーディングよりも優れた戦略となることが多いです。これは、ApsaraDB for MongoDB が内部ハッシュ関数を使用してキー値に基づいてデータを均等にシャード間で分散させるためです。一方、レンジシャーディングはキー値の範囲に基づいてデータを分散させるため、「ホット」チャンクに新しいデータが集中し、そのシャードでディスク I/O が高くなり、短期的なデータの不均衡が発生する可能性があります。

不適切なシャードキーフィールド

各シャード上のチャンク数がほぼ同程度であっても、データの大部分が少数のチャンクに集中している場合があります。その結果、「ホット」チャンクを含むシャードは、他のシャードよりも著しく多くのデータを格納することになります。sh.status() コマンドを実行し、ApsaraDB for MongoDB ランタイムログを確認すると、以下のような警告メッセージが表示されることがあります。

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" }

Mongos バランサーは、各シャード上のチャンク数を基準にデータのバランスを判断します。このため、チャンク数はバランスが取れているが、実際のデータ分布が大きく偏っているというシナリオが発生することがあります。これは、チャンク内のシャードキー値がほぼ同一であるために起こります。チャンクが 64 MB の分割しきい値に達すると、MongoDB はそれを分割して空のチャンクを作成します。時間の経過とともに、チャンク数は増加し移行が発生しますが、移行されるチャンクは多くの場合空であるため、チャンク数はバランスが取れていてもデータは不均衡のままになります。これを修正するには、高カーディナリティのフィールドをシャードキーとして使用するようにシャーディングポリシーを再設計してください。

シャードクラスター内の非シャードデータベース

ApsaraDB for MongoDB のシャードクラスターインスタンスは、シャードおよび非シャードの両方のデータベースをサポートしています。非シャードデータベースのすべてのデータは単一のプライマリシャード上に存在するため、そのデータベースが大規模な場合、そのプライマリシャードは他のシャードよりも著しく多くのデータを格納することになります。

この問題は、ソースの mongos クラスターから新しいクラスターにデータをインポートする際に、インポート前に送信先クラスターでシャーディングを設定し忘れた場合にも発生します。

これらの問題に対処するには、以下の方法を推奨します。

• 送信先クラスターをインポートで初期化する場合は、開始前にシャーディングを設計および有効にしてください。

• サイズがほぼ同じで多数の非シャードデータベースがある場合は、movePrimary コマンドを使用して、特定のデータベースを異なるシャードに移動してください。

• 非常に大規模な非シャードデータベースが存在する場合は、シャーディングを適用するか、スタンドアロンのレプリカセットインスタンスに移行することを推奨します。

• この状況が発生してもディスク領域に余裕がある場合は、この問題を無視することも可能です。