ストレージ使用量は、ApsaraDB RDS for MySQLインスタンスのパフォーマンスを測定するために使用される重要な指標です。 使用可能なストレージが不十分な場合、RDSインスタンスに重大な問題が発生する可能性があります。 たとえば、データの書き込みまたはバックアップが失敗し、ストレージ容量の拡張タスクに必要な時間が異常に長くなります。 このトピックでは、RDSインスタンスのストレージ使用状況を表示する方法と、ストレージの問題をトラブルシューティングする方法について説明します。
ストレージ使用量の表示
ApsaraDB RDSコンソールにログインし、RDSインスタンスの [基本情報] ページに移動します。 ページの使用状況統計セクションで、RDSインスタンスの全体的なストレージ使用状況を表示します。 使用状況統計セクションでは、さまざまなデータ型の現在または過去のストレージ使用状況は提供されません。
ApsaraDB RDSコンソールで、さまざまなデータタイプのストレージ使用量を確認できます。 詳細については、「モニタリング情報の表示」をご参照ください。
ApsaraDB RDSコンソールにログインします。 RDSインスタンスの詳細ページの左側のナビゲーションウィンドウで、 を選択します。 表示されるページで、[ストレージ分析] タブをクリックして、データとログで使用されるストレージの比較、ストレージ使用率の傾向、上位N個のデータベースで使用されるストレージの詳細、上位N個のテーブルで使用されるストレージの詳細など、ストレージ使用率の詳細を表示します。
説明[テーブルスペース] セクションでは、データストレージの使用状況、インデックスストレージの使用状況、および使用可能なストレージを表示できます。 使用可能なストレージは、テーブルに割り当てられている未使用のストレージの量です。
ストレージ使用量は、収集された統計から得られ、不正確であり得る。
指定したデータベースにログオンします。 次に、
SHOW TABLE STATUS LIKE '<Table name>';ステートメントを実行して、テーブルのストレージ使用状況を表示します。
インデックスの過剰によるストレージ不足のトラブルシューティング
現象
ほとんどの場合、テーブルにはプライマリキーインデックスとセカンダリインデックスが含まれます。 セカンダリインデックスが多いほど、テーブルのストレージ使用量が多いことを示します。
解決策
テーブルのデータ構造を最適化して、セカンダリインデックスを減らします。
大きなフィールドによるストレージ不足のトラブルシューティング
現象
バイナリラージオブジェクト (BLOB) 、TEXT、またはVARCHARデータ型の大きなフィールドがテーブルのスキーマで定義されている場合、テーブルは大量のストレージを占有します。
解決策
データをテーブルに挿入する前にデータを圧縮します。
過剰なアイドルテーブルスペースによるストレージ不足のトラブルシューティング
現象
InnoDBテーブルの断片化率は高いです。 これは、過剰な数のアイドルテーブルスペースをもたらす。 InnoDBは、ページごとにテーブルスペースを管理します。 ページ全体のいくつかのレコードが削除され、レコードが削除された位置に新しいレコードが挿入されない場合、多数のアイドルテーブルスペースが生成されます。
解決策
アイドルテーブルスペースを表示するには、
SHOW TABLE STATUS LIKE '<Table name>';ステートメントを実行します。 アイドルテーブルスペースが大きすぎる場合は、OPTIMIZE TABLE <Table name>;文を実行してテーブルスペースを最適化します。
一時テーブルが大きすぎることによるストレージ不足のトラブルシューティング
現象
テーブルに対してインデックス、半結合操作、または個別操作を使用しないソート操作を実行すると、一時テーブルが作成されます。 一時テーブルに過剰な量のデータが含まれている場合、一時テーブルのストレージ使用量が過剰に高くなる可能性があります。
データ定義言語 (DDL) ステートメントを実行してテーブルスペースを再構築すると、インデックスベースのソート操作から生成される一時テーブルが大きくなります。 これは、テーブルスペースを使用して大きなテーブルのデータを格納する場合に適用されます。 RDSインスタンスがMySQL 5.6またはMySQL 5.7を実行している場合、すぐにフィールドを追加することはできません。 一部のDDLステートメントは、新しいテーブルでのみ実行できます。 テーブルでこれらのDDLステートメントを実行するリクエストを送信すると、システムはテーブルを作成し、新しいテーブルでこれらのDDLステートメントを実行します。 新しいテーブルは、元のテーブルのレプリカです。 したがって、これらのDDLステートメントが実行されているときに、2つのファイルレプリカを見つけることができます。 これらのDDL文が実行されると、元のテーブルが削除されます。
解決策
DDLステートメントの実行に基づくプランを表示します。 Using Temporaryフィールドが指定されているかどうかを確認できます。
大きなテーブルでDDLステートメントを実行する前に、RDSインスタンスに十分なストレージがあるかどうかを確認してください。 使用可能なストレージが不十分な場合は、RDSインスタンスのストレージ容量を拡張します。 詳細については、「ApsaraDB RDS For MySQLインスタンスの仕様の変更」をご参照ください。
ストレージ使用量の最適化
自動表領域フラグメントのリサイクル機能を有効にします。 詳細については、「自動表領域フラグメントのリサイクル」をご参照ください。 この機能を有効にすると、プライマリRDSインスタンスは自動的にOPTIMIZE TABLEステートメントを実行して、表領域フラグメントを再利用します。 これにより、物理テーブルスペースのフラグメントをクリーンアップできます。
クラウドディスクを使用します。 詳細については、「ストレージタイプ」をご参照ください。 クラウドディスクは、ローカルディスクよりも大きなストレージ容量を提供します。
X-Engineストレージエンジンを使用します。 詳細については、「X-Engineの概要」をご参照ください。 X-Engineは高い圧縮比をサポートします。
PolarDBを使用します。 詳細については、「PolarDBの概要」をご参照ください。 PolarDBは、分散ストレージシステムに基づいて開発されます。 それは自動的に拡張することができる大きい記憶容量を提供する。 PolarDB Archive Database EditionとX-Engineの組み合わせにより、さまざまなデータ型のストレージ使用量が大幅に削減されます。
RDSインスタンスがRDS High-availability Editionを実行し、クラウドディスクを使用している場合は、自動ストレージ拡張機能を有効にします。 この機能により、ストレージ不足によるRDSインスタンスのロックが防止されます。 詳細については、「自動ストレージ拡張の設定」をご参照ください。
AnalyticDB for MySQLを使用します。 詳細については、「AnalyticDB For MySQLの概要」をご参照ください。