ストレージ容量不足による ApsaraDB RDS for MySQL の自動ロックの解除 - ApsaraDB RDS

ストレージ容量が枯渇すると、ApsaraDB RDS for MySQL はデータ損失を防ぐため、インスタンスを自動的にロックします。「ロック済み」状態では、書き込み操作は一切受け付けられません。本トピックでは、この問題の一般的な原因と、それぞれに対する解決方法について説明します。

説明

ディスク領域を解放した後、システムがインスタンスを自動的にロック解除するまでに 5～15 分程度かかります。

原因の診断

ApsaraDB RDS コンソールにログインします。上部のナビゲーションバーで、該当インスタンスが配置されているリージョンを選択し、その後、インスタンス ID をクリックします。
左側のナビゲーションウィンドウで、[モニタリングとアラート] をクリックして、どのファイルタイプが最もストレージを消費しているかを確認します。詳細については、「モニタリング情報の表示」をご参照ください。
以下の表を用いて原因を特定し、該当する解決方法に進んでください。

原因とその解決方法

原因	説明	解決方法
データファイル	インスタンス上に多数のデータファイルが格納されています。	データファイルによるストレージ枯渇の解決
バイナリログファイル	不適切なログバックアップポリシー、または大規模トランザクションにより、過剰なバイナリログファイルが生成されます。	バイナリログファイルによるストレージ不足の対処
一時ファイル	SQL クエリにおける並べ替え、集計、結合などの処理で大量の一時ファイルが生成されます。また、大規模トランザクションでは、コミット前にキャッシュされるログファイルも生成されます。	一時ファイルによるストレージ不足の解消
システムファイル（undo ファイル）	InnoDB テーブルに対する長時間実行クエリと大規模なデータ更新が組み合わさることで、多数の undo ファイルが生成されます。説明 MySQL 8.0 では、システムが undo ファイルを自動的に削除するため、この現象は発生しません。	システムファイルによるストレージ枯渇の解決
一般クエリログ	`general_log` パラメーターが `ON` に設定されている場合、すべてのクエリ、挿入、更新、削除操作が記録されます。クエリの実行時間が長期間にわたる場合や、ログが定期的にクリーンアップされない場合、ログファイルが肥大化します。	一般クエリログによるストレージ枯渇の解決

一般クエリログのサイズ確認

一般クエリログがストレージ容量不足の原因であることを確認するには、以下の手順を実行してください。

モニタリング情報で sys_data_size が異常に大きいかどうかを確認します。詳細については、「モニタリング情報を表示する」をご参照ください。
「general_log」パラメーターが「ON」に設定されていることを確認します。詳細については、「ApsaraDB RDS for MySQL インスタンスのパラメーターを表示する」をご参照ください。
インスタンスに接続し、次のクエリを実行してログテーブルのサイズを確認します。詳細については、「ApsaraDB RDS for MySQL インスタンスへの接続」をご参照ください。
説明
このクエリは、information_schema.TABLES から mysql.general_log テーブルのサイズ（MB 単位）を返します。返される値はサンプルデータであり、実際の値とは異なる場合があります。
```
SELECT table_schema AS 'Database', table_name,
SUM(data_length + index_length + data_free)/1024/1024 AS "Table size in MB",
SUM(DATA_FREE)/1024/1024 AS "Fragment size in MB"
FROM information_schema.TABLES
WHERE table_name='general_log'
```