スキップしてコンテンツを表示

空き容量が不足している RDS for MySQL または MariaDB インスタンスのトラブルシューティング方法を教えてください

所要時間3分
0

Amazon Relational Database Service (Amazon RDS) for MySQL または MariaDB インスタンスで空き容量が不足しているため、トラブルシューティングしたいです。

簡単な説明

Amazon RDS for MySQL または MariaDB インスタンスで空き容量がなくなった状況をトラブルシューティングするには、DB インスタンスでの合計ストレージ使用量を確認し、容量を消費する要因を特定してください。DB インスタンスのスペースは、次のオブジェクトに使用できます。

  • ユーザー作成のデータベース
  • 一時テーブル
  • バイナリログまたは MySQL スタンバイインスタンスのリレーログ (リードレプリカを使用する場合)
  • InnoDB テーブルスペース
  • 一般ログ、スロークエリログ、エラーログ

ストレージスペースを確認し、そのスペースを使用しているユーザーを特定後、スペースを再利用します。その後、FreeStorageSpace メトリックを監視するとストレージ容量に関する今後の問題を防止できます。

注: 使用可能なストレージが突然減少した場合は、SHOW FULL PROCESSLIST コマンドを実行し、DB インスタンスレベルでクエリを確認してください。SHOW FULL PROCESSLIST コマンドは、すべてのアクティブな接続と各接続によって実行されるクエリに関する情報を提供します。長期間アクティブになっているトランザクションを確認するには、まず INFORMATION_SCHEMA.INNODB_TRX または SHOW ENGINE INNODB STATUS コマンドを実行します。次に、出力を確認します。

解決策

ストレージフル状態の Amazon RDS for MySQL または MariaDB インスタンスをトラブルシューティングするには、次の手順を実行します。

MySQL DB インスタンスで使用されている合計容量を確認する

ユーザーが作成した各データベースのサイズを特定する

SELECT SUBSTRING_INDEX(TABLESPACE_NAME,"/",1) AS DATABASE_NAME, ROUND((DATA_FREE/1024/1024/1024),3) AS 'REUSABLE (GB)', ROUND(SUM((TOTAL_EXTENTS * EXTENT_SIZE)/1024/1024/1024),3) AS 'TOTAL (GB)' FROM INFORMATION_SCHEMA.FILES GROUP BY DATABASE_NAME ORDER BY 'TOTAL (GB)'  DESC;

指定したユーザーデータベースでの、各テーブルのサイズを確認します。
注: example-database-name を実際のデータベース名に置き換えてください。

SELECT SUBSTRING_INDEX(TABLESPACE_NAME,"/",-1) as 'TABLE_NAME', ROUND((total_extents * extent_size)/1024/1024/1024,3) AS "TableSizeinGB" from information_schema.files WHERE FILE_NAME LIKE 'example-database-name';

MariaDB インスタンスで使用されている合計容量を確認する

ユーザーが作成した各データベースのサイズを特定します。

mysql> SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024/1024,2) "size in GB" FROM information_schema.tables GROUP BY 1 ORDER BY 2 DESC;

指定したユーザーデータベースでの、各テーブルのサイズを確認します。
注: 実際のものでそれぞれ、example-database をデータベース名に、example-table をテーブル名に置き換えます。

mysql> SELECT table_schema "example-database", example-table,(data_length + index_length)/1024/1024/1024 AS "TableSizeinGB" from information_schema.tables where table_schema='database_name';

一時テーブルを確認する

InnoDB ユーザーが作成した一時テーブルとディスク上の内部一時テーブルは、ibtmp1 という名前の一時テーブルスペースファイルに作成されます。一時テーブルスペースファイルは、MySQL データディレクトリの ibtmp2 に拡張される可能性があります。一時テーブル ibtmp1 がストレージを過剰使用している場合は、DB インスタンスを再起動してスペースを解放してください。

注: InnoDB テーブルスペースのファイルサイズをクエリするには、MySQL バージョン 5.7 以降または MySQL バージョン 8.0 以降のみを使用できます。

InnoDB 一時テーブルスペースを特定します。

mysql> SELECT file_name, tablespace_name, table_name, engine, index_length, total_extents, extent_size from information_schema.files WHERE file_name LIKE '%ibtmp%';

グローバル一時テーブルスペースのデータファイルが占有しているディスク容量を再利用するには、MySQL サーバーまたは DB インスタンスを再起動します。詳細については、MySQL のウェブサイトで「一時テーブルスペース」を参照してください。

InnoDB テーブルスペースを確認する

クエリが原因で、MySQL は削除できない内部一時テーブルを作成する場合があります。これらの一時テーブルは、info_schema 内の tables という名前のテーブルには属していません。詳細については、MySQL ウェブサイトの「MySQL での内部一時テーブルの使用」を参照してください。

内部一時テーブルを特定します。

mysql> SELECT * FROM information_schema.innodb_sys_tables WHERE name LIKE '%#%';

InnoDB システムテーブルスペースを特定します。

mysql> SELECT file_name, tablespace_name, table_name, engine, index_length, total_extents, extent_size from information_schema.files WHERE file_name LIKE '%ibdata%';

注: 上記のクエリは、MySQL バージョン 5.7 以降または MySQL バージョン 8.0 以降でサポートされています。

システムテーブルスペースのサイズが拡大すると、そのサイズは縮小できません。InnoDB テーブルをダンプし、そのテーブルを新しい MySQL DB インスタンスにインポートすると、この問題に対処できます。システムテーブルスペースの拡大を避けるには、file-per-table テーブルスペースを使用してください。詳細については、MySQL のウェブサイトで「File-per-table テーブルスペース」を参照してください。

Innodb_file_per_table を有効にした場合、各テーブルはデータとインデックスを独自のテーブルスペースファイルに保存します。スペースを再利用するには、OPTIMIZE TABLE を実行します。詳細については、MySQL のウェブサイトで 「OPTIMIZE TABLE ステートメント」を参照してください。

注: OPTIMIZE TABLE コマンドは、COPY アルゴリズムを使用して元のテーブルと同じサイズの一時テーブルを作成します。OPTIMIZE TABLE を実行する前に、使用できるディスク容量があることを確認してください。

テーブルを最適化するには、次のコマンドを実行します。
注: example-table を、最適化するテーブルに置き換えてください。

mysql> OPTIMIZE TABLE example-table-name;

(オプション) テーブルを再構築するには、次のコマンドを実行します。
注: example-table を、最適化するテーブルに置き換えてください。

mysql> ALTER TABLE example-table-name ENGINE=INNODB;

バイナリログを確認する

Amazon RDS インスタンスで自動バックアップを有効にした場合、DB インスタンスではバイナリログが自動的に有効になります。バイナリログはディスクに保存され、ストレージ容量を消費しますが、バイナリログの保持設定が適用されるたびに削除されます。インスタンスでは、binlog の保持値はデフォルトで Null に設定されるため、ファイルはすぐに削除されます。

ストレージ容量不足の問題を回避するには、Amazon RDS for MySQL でバイナリログ保持期間に適切な値を設定してください。

バイナリログの保持期間 (時間単位) を確認するには、mysql.rds_show_configuration コマンドを実行します。

CALL mysql.rds_show_configuration;

バイナリログが使用する領域を削減するには、バイナリログを保持する期間を短くします。値が NULL の場合、ログはすぐに削除されます。

アクティブインスタンスに対するスタンバイインスタンスがある場合は、スタンバイインスタンスの ReplicaLag メトリクスを監視します。ReplicaLag メトリクスは、バイナリログがアクティブインスタンスで処理されたり、スタンバイインスタンスでログをリレーしたりする際に発生する遅延を示します。

消去またはレプリケーションの問題が発生した場合、バイナリログは経時的に蓄積され、追加のディスク容量を消費する可能性があります。インスタンス上のバイナリログの数およびファイルサイズを確認するには、SHOW BINARY LOGS コマンドを使用します。詳細については、MySQL のウェブサイトで「SHOW BINARY LOGS ステートメント」を参照してください。

DB インスタンスがレプリケーションスタンバイインスタンスとして機能している場合は、Relay_Log_Space を参照してリレーログのサイズを確認してください。

SHOW SLAVE STATUS\G

MySQL ログ (一般ログ、スロークエリログ、エラーログ) を確認する

スロークエリ、FILE タイプの一般ログ、およびエラーログのサイズを確認するには、データベースログファイルの一覧を表示します。スロークエリログテーブルと一般ログテーブルがストレージを過剰に使用している場合は、ログテーブルを手動でローテーションしてテーブルベースの MySQL ログを管理してください。

古いデータを削除してディスク容量を再利用するには、次のコマンドを 2 回続けて実行します。

mysql> CALL mysql.rds_rotate_slow_log;mysql> CALL mysql.rds_rotate_general_log;

注: テーブルには、ログの正確なファイルサイズは表示されません。slow_log および general_log において、log_outputパラメータ値File に変更します。

Amazon RDS DB インスタンスを監視、スケーリングする

Amazon RDS インスタンスを監視、スケーリングするには、次の手順を実行します。

コメントはありません

関連するコンテンツ