ApsaraDB RDS for MySQLインスタンスのストレージ不足の問題の原因とトラブルシューティング方法 - ApsaraDB RDS

ストレージ使用量は、ApsaraDB RDS for MySQLインスタンスのパフォーマンスを測定するために使用される重要な指標です。使用可能なストレージが不十分な場合、RDSインスタンスに重大な問題が発生する可能性があります。たとえば、データの書き込みまたはバックアップが失敗し、ストレージ容量の拡張タスクに必要な時間が異常に長くなります。このトピックでは、RDSインスタンスのストレージ使用状況を表示する方法と、ストレージの問題をトラブルシューティングする方法について説明します。

ストレージ使用量の表示

RDSインスタンスのストレージは、ユーザーデータベースのデータ、システムデータベースのデータ、ログ、一時テーブルとファイルによって占有されます。標準モニタリング機能を使用して、RDSインスタンスのストレージ使用量を表示できます。

ApsaraDB for RDS コンソールにログインします。必要なRDSインスタンスのIDをクリックして、インスタンスの詳細ページに移動します。
表示されるページの左側のナビゲーションウィンドウで、[モニタリングとアラート] をクリックします。表示されるページで、[標準モニタリング] タブをクリックして、[MySQLストレージ使用済み容量 (MB)] セクションでストレージ使用量を表示します。
セクション名の横にあるアイコンをクリックして、セクション内のメトリックの説明を表示します。詳細については、「モニタリング情報の表示」をご参照ください。

ソリューションの概要

ストレージ不足は、さまざまな種類のファイルが蓄積されているために発生します。 RDSインスタンスのストレージ使用状況を表示する場合は、ファイルのストレージ使用状況をメモし、ファイルタイプに基づいてソリューションを選択します。 次の表に、ファイルの種類と対応するソリューションを示します。

ファイルタイプ	標準モニタリングのパラメータ名	ストレージ分析のパラメーター名	解決策
一時ファイル	`temp_file_サイズ`	`一時ファイルのデータ量`	一時ファイルの蓄積によるストレージ不足のトラブルシューティング
バイナリログファイル	`binlog_size`	`バイナリログ`	バイナリログファイルの蓄積によるストレージ不足のトラブルシューティング
ログファイルを元に戻す	`undolog_サイズ`	`Undoログによる使用量`	システムファイルの蓄積によるストレージ不足のトラブルシューティング
一般ログファイル	`general_log_サイズ`	`インスタンスエラーログ、パフォーマンスエージェントログ、リカバリログを含む通常ログの使用状況`	一般的なログの蓄積によるストレージ不足のトラブルシューティング
ユーザーデータファイル	`user_data_size`	`ユーザーデータベースによる使用量`	ユーザーデータファイルの蓄積によるストレージ不足のトラブルシューティング

RDSインスタンスのテーブルスペースフラグメントとデータベースインデックスにも注意する必要があります。

Tablespaceフラグメントの蓄積により、ストレージが不足する場合があります。詳細については、「表領域フラグメントの蓄積によるストレージ不足のトラブルシューティング」をご参照ください。
データベースに不適切なインデックスを設定すると、インデックスファイルが蓄積され、記憶容量が不足するおそれがあります。詳細については、「インデックスファイルの蓄積によるストレージ不足のトラブルシューティング」をご参照ください。

重要

緊急の場合は、手動でディスクのサイズを変更して、できるだけ早い機会にRDSインスタンスのロックを解除することをお勧めします。ワークロードを期待どおりに実行したら、蓄積されたファイルの種類に基づいてストレージをクリアできます。詳細については、「インスタンス仕様の変更」をご参照ください。ほとんどの場合、RDSインスタンスはディスクのサイズ変更から約5分後にロック解除されます。

一時ファイルの蓄積によるストレージ不足のトラブルシューティング

大量の一時ファイルがRDSインスタンスに書き込まれるか、大規模トランザクションの大量のバイナリログファイルがRDSインスタンスにキャッシュされてから、大規模トランザクションがコミットされます。その結果、RDSインスタンスのストレージ容量が使い果たされます。データの並べ替え、データのグループ化、テーブルの関連付けを必要とするSQL文が実行されると、一時ファイルが生成されます。この場合、システムは自動的にRDSインスタンスをロックしてデータの損失を防ぎ、RDSインスタンスにデータを書き込むことはできません。

解決策: 詳細については、「ApsaraDB RDS For MySQLインスタンスが一時ファイルによってストレージ容量が使い果たされたためにロック状態になった場合の対処方法」をご参照ください。

MySQL 5.7以前を実行するRDSインスタンス: システムが一時ファイルを自動的に削除できるように、RDSインスタンスを再起動することを推奨します。詳細については、「ApsaraDB RDS for MySQLインスタンスが一時ファイルによってストレージ容量が使い果たされたためにロック状態になっている場合はどうすればよいですか。」をご参照ください。
MySQL 8.0を実行するRDSインスタンス: RDSインスタンスがロックされている場合、すべてのセッションが終了し、システムは自動的にロールバックを実行します。ロールバックが完了すると、システムは自動的に一時ファイルを解放します。
RDSインスタンスが長期間にわたって自動的にロック解除されない場合、SHOW PROCESSLISTステートメントを実行してすべてのセッションのステータスを表示し、[Copy to tmp] テーブルおよび [Sending data] の状態にあるセッションを特定し、killコマンドを実行して特定されたセッションを終了する必要があります。

バイナリログファイルの蓄積によるストレージ不足のトラブルシューティング

大規模なトランザクションを実行した後、短時間で大量のバイナリログファイルが生成され、RDSインスタンスのストレージ容量が使い果たされる可能性があります。その後、RDSインスタンスは自動的にロックされ、データの損失を防ぎます。この場合、RDSインスタンスにデータを書き込むことはできません。

ソリューション: 詳細については、「ApsaraDB RDS For MySQLインスタンスのストレージ容量がバイナリログファイルによって使い果たされた場合の対処方法」をご参照ください。

バイナリログファイルのアップロード: Binlogsのアップロード機能を使用して、RDSインスタンスのバイナリログファイルをObject Storage Service (OSS) バケットにアップロードできます。バイナリログファイルがアップロードされると、ファイルはRDSインスタンスから自動的に削除されます。詳細については、「バイナリログファイルの管理」をご参照ください。
バイナリログファイルの保持ポリシーの変更: ApsaraDB RDSコンソールにログインし、RDSインスタンスの [バックアップと復元] ページに移動します。 [バックアップ戦略] タブの [ローカルログ保持ポリシー] セクションでは、バイナリログファイルのパラメーター (保持期間、最大ストレージ容量使用量、使用可能なストレージ容量など) を変更できます。 RDSインスタンスのバイナリログファイルが占有するストレージが指定されたしきい値に達した場合、システムは、バイナリログファイルが占有するストレージがしきい値を下回るまで、以前のバイナリログファイルを削除します。

テーブルスペースフラグメントの蓄積によるストレージ不足のトラブルシューティング

InnoDBは、ページごとにテーブルスペースを管理します。 DELETEまたはUPDATE文を実行してデータを削除または更新すると、削除または更新されたデータの場所またはページは「再利用可能」とマークされますが、ディスクファイルのサイズは変更されず、テーブルスペースは再利用されません。元の表領域を再利用できない場合、表領域フラグメントが生成され、RDSインスタンスのストレージを占有します。

ソリューション: 詳細については、「OPTIMIZE TABLEステートメントを使用してApsaraDB RDS For MySQLインスタンスのテーブルスペースをリリースする方法」をご参照ください。

テーブルスペースのフラグメントを管理するために必要なSQL文を実行します。OPTIMIZE TABLE文を実行して、テーブルスペースのフラグメントを管理できます。
データ管理 (DMS) を使用してテーブルを最適化する: DMSを使用してApsaraDB RDS for MySQLインスタンスにログインできます。 DMSコンソールの左側のナビゲーションウィンドウで、[接続されたインスタンス] を展開し、テーブル名を右クリックして、[バッチ操作テーブル] を選択します。表示されるページで、テーブルスペースフラグメントを管理するテーブルを選択し、[テーブルメンテナンス] > [テーブルの最適化] を選択します。
自動フラグメント再利用機能を有効にする: [Autonomy Services] > [診断] ページの [Autonomy Center] タブに移動し、[Autonomy Serviceの設定] をクリックして自律機能を有効にし、[最適化とスロットル] タブの自動フラグメント再利用機能を有効にします。詳細については、「自動フラグメント再利用機能の使用」をご参照ください。

システムファイルの蓄積によるストレージ不足のトラブルシューティング

ほとんどの場合、大きなシステムファイルは主に大きなアンドゥファイルによって引き起こされます。 InnoDBテーブル上のクエリが長時間実行されており、クエリ中にテーブル内で大量のデータが更新されると、大量のアンドゥデータが生成され、ストレージを占有してストレージ容量が使い果たされます。データの損失を防ぐため、システムは自動的にRDSインスタンスをロックします。 RDSインスタンスが [ロック] 状態になります。

ソリューション: 詳細については、「ApsaraDB RDS For MySQLインスタンスのストレージ容量がシステムファイルによって使い果たされた場合の対処方法」をご参照ください。

MySQL 8.0を実行するRDSインスタンス: アンドゥファイルは自動的に削除されます。
MySQL 5.7を実行するRDSインスタンス:
- innodb_undo_tablespacesパラメーターの値が2に設定されている場合、RDSインスタンスのundoファイルは独立したundoテーブルスペースに格納され、削除できます。アンドゥファイルのサイズがinnodb_max_undo_log_sizeパラメーターの値を超え、アンドゥファイル内のログがアクティブなトランザクションで不要になった場合、システムはアンドゥファイルを切り捨ててストレージリソースを解放します。
- innodb_undo_tablespacesパラメーターの値が0に設定されている場合、独立したundo tablespacesは使用されません。 undoファイルはibdata1システムテーブルスペースに格納され、削除できません。この場合、必要なメジャーエンジンバージョンを実行するRDSインスタンスを作成し、新しいRDSインスタンスにデータを移行できます。 RDSインスタンスのメジャーエンジンバージョンをMySQL 8.0にアップグレードすることもできます。詳細については、「メジャーエンジンのバージョンのアップグレード」をご参照ください。
MySQL 5.5またはMySQL 5.6を実行するRDSインスタンス: 元に戻すファイルは削除できません。この場合、RDS High-availability EditionまたはMySQL 8.0でRDSインスタンスをMySQL 5.7にアップグレードすることを推奨します。
説明
RDS High-availability EditionでMySQL 5.7を実行するRDSインスタンスのinnodb_undo_tablespacesパラメーターが2に設定されている場合、RDSインスタンスのundoファイルは独立したundoテーブルスペースに格納され、削除できます。

一般的なログの蓄積によるストレージ不足のトラブルシューティング

general_logパラメーターをONに設定すると、mysql.general_logという名前のテーブルが生成され、RDSインスタンスで実行されたすべての操作と操作の詳細が記録されます。操作は、選択、挿入、更新、および削除操作を含む。大量のクエリが実行されている場合や、mysql.general_logテーブルが長期間クリアされていない場合、テーブルは大量のストレージリソースを消費します。その結果、RDSインスタンスのストレージ容量が使い果たされます。

ソリューション: 詳細については、「ApsaraDB RDS For MySQLの一般的なクエリログ機能に関するFAQ」をご参照ください。

一般ログの収集を無効にする: general_logパラメーターをOFFに設定して、新しいログが生成されないようにすることができます。詳細は、「インスタンスパラメーターの変更」をご参照ください。
一般的なログファイルの削除: RDSインスタンスにログインし、TRUNCATE TABLE mysql.general_log; ステートメントを実行して、一般的なログファイルを削除します。
問題をデバッグまたはトレースする場合は、general_logパラメーターを短時間ONに設定することを推奨します。問題を解決したら、できるだけ早くgeneral_logパラメーターをOFFに設定します。

ユーザーデータファイルの蓄積によるストレージ不足のトラブルシューティング

ユーザーデータファイルが長期間削除されない場合、またはファイル内のテーブルにBLOB、TEXT、およびlong VARCHARのデータ型のフィールドが含まれている場合、大量のストレージが占有されます。その結果、ストレージ容量が使い果たされる。この場合、RDSインスタンスはデータの損失を防ぐために自動的にロックされ、RDSインスタンスにデータを書き込むことはできません。

解決策: 詳細については、「ApsaraDB RDS For MySQLインスタンスがデータファイルによってストレージ容量が使い果たされたためにロック状態になった場合の対処方法」をご参照ください。

データの削除: DROPまたはTRUNCATEステートメントを実行して、不要になったデータを削除できます。
データの圧縮: 大きなフィールドを圧縮し、圧縮したフィールドをデータベースに保存して、ストレージの使用量を減らすことができます。

インデックスファイルの蓄積によるストレージ不足のトラブルシューティング

データベースインデックスはファイルとしてディスクに保存されます。データベースに不適切なインデックスを設定したり、多数のセカンダリインデックスを作成したりすると、大きなインデックスファイルが生成されたり、インデックスファイルが蓄積されたりします。その結果、記憶容量が不足するおそれがある。

解決策:

適切なフィールドを選択してインデックスを作成する: プライマリキーインデックスに加えて、頻繁にクエリされるフィールド、並べ替えが必要なフィールド、またはテーブル間結合に頻繁に使用されるフィールドのインデックスを作成して、ストレージの使用量を削減することを推奨します。また、単一列インデックスの代わりにフェデレーションインデックスを作成することをお勧めします。
インデックスの削除: 長期間使用されていないインデックス、またはストレージ使用量の削減に不要になったインデックスを削除できます。テーブルのデータ構造を最適化して、セカンダリインデックスを減らすこともできます。