RDS for MySQL インスタンスのストレージ使用量は、監視すべき重要なメトリックです。ストレージ領域が不足すると、深刻な問題が発生する可能性があります。たとえば、データベースが読み取り専用になったり、バックアップが失敗したり、ストレージのスケールアウトタスクに時間がかかりすぎたりすることがあります。このトピックでは、ストレージ使用量の表示方法と、一般的なストレージ問題の解決策について説明します。
ストレージ使用量の表示
RDS for MySQL インスタンスのストレージ領域には、ユーザーデータ、システムデータ、各種ログ、および一時ファイルが含まれます。標準モニタリング機能を使用してストレージ使用量を確認できます。
RDS コンソールにログインします。インスタンス ID をクリックして、製品ページに移動します。
左側のナビゲーションウィンドウで、[監視とアラート] > [標準モニタリング] を選択します。[MySQL ストレージ使用量] ビューでインスタンスのストレージ使用量を確認できます。
ビュータイトルの横にある
アイコンをクリックすると、各パラメーターの説明が表示されます。詳細については、「監視情報の表示」をご参照ください。
データベースのシステムファイルとログファイルはストレージ領域を占有します。それらが使用する領域の量は、データベースのペイロードやデータ保持ポリシーなどの要因によって異なります。
解決策の概要
ストレージ領域の不足は、インスタンス内のさまざまなファイルの蓄積によって引き起こされます。インスタンスのストレージを確認する際は、以下のファイルの領域使用量に注目し、ファイルの種類に応じた解決策を選択してください。
ファイル名 | 標準モニタリングのパラメーター | スペース分析のパラメーター | 解決策 |
一時ファイル |
|
| |
Binlog ファイル |
|
| |
undo ログファイル |
|
| |
general ログファイル |
|
| |
ユーザーデータファイル |
|
|
上記のファイルに加えて、インスタンスの断片化とデータベースのインデックスも確認する必要があります。
断片化の蓄積も、利用可能なストレージ領域の不足を引き起こす可能性があります。詳細については、「断片化によるストレージ不足」をご参照ください。
データベースが非効率的なインデックス作成ポリシーを使用している場合、インデックスファイルが蓄積され、インスタンスの領域が不足する可能性があります。詳細については、「インデックスファイルの蓄積によるストレージ不足」をご参照ください。
緊急時には、まず 手動でディスクサイズを変更 して、できるだけ早くインスタンスのロックを解除することをお勧めします。サービスが復旧した後、ファイルの蓄積に基づいてストレージ領域をクリーンアップできます。ほとんどの場合、ディスクのサイズ変更後、約 5 分でインスタンスのロックが解除されます。サイズ変更に必要な時間は、ストレージタイプとデータ量によって異なります。タスクハブ でディスクのサイズ変更の進捗状況を確認できます。
一時ファイルの蓄積によるストレージ不足
大量の一時ファイルが RDS インスタンスに書き込まれるか、大規模なトランザクションがコミットされる前に大量のバイナリログファイルが RDS インスタンスにキャッシュされます。その結果、RDS インスタンスのストレージ容量が使い果たされます。一時ファイルは、データのソート、データのグループ化、およびテーブルの関連付けを必要とする SQL 文が実行されるときに生成されます。この場合、システムはデータ損失を防ぐために RDS インスタンスを自動的にロックし、RDS インスタンスにデータを書き込むことはできません。
解決策: 詳細については、「RDS for MySQL の一時ファイル蓄積の解決策」をご参照ください。
MySQL 5.7 以前: インスタンスを再起動します。システムは自動的に一時ファイルを削除します。
MySQL 8.0: インスタンスがロックされると、すべてのユーザーセッションを終了し、自動ロールバックを開始します。ロールバックが完了すると、システムは自動的に一時ファイルを解放します。
インスタンスが長時間自動的にロック解除されない場合は、
show processlistコマンドを実行してすべてのセッションのステータスを表示します。Copy to tmp tableやSending dataなどのステータスのセッションを見つけ、killコマンドを使用して手動で終了させます。
バイナリロギング (ローカルログ) ファイルの蓄積によるストレージ不足
大規模なトランザクションを実行した後、短時間で大量のバイナリログファイルが生成され、RDS インスタンスのストレージ容量が使い果たされる可能性があります。その後、データ損失を防ぐために RDS インスタンスは自動的にロックされます。この場合、RDS インスタンスにデータを書き込むことはできません。
解決策: 詳細については、「MySQL Binlog ファイル蓄積の解決策」をご参照ください。
ワンクリックバイナリログアップロード: RDS の ワンクリックバイナリログアップロード 機能を使用して、RDS インスタンスから OSS にバイナリログファイルをアップロードできます。アップロードが完了すると、RDS はアップロードされたバイナリログファイルを自動的に削除します。
ローカルログ保持ポリシーの変更: RDS コンソールで、[バックアップとリカバリ] ページに移動します。[バックアップポリシー] タブをクリックします。[ローカルログ保持ポリシー] の横にある [編集] をクリックします。保持期間、最大ストレージ使用量、利用可能なストレージ領域などのパラメーターを変更できます。インスタンスに保存されているローカルログの量が指定されたしきい値に達すると、ストレージ使用量がしきい値を下回るまで、システムは最も古いローカルログを削除します。
断片化の蓄積による領域不足
InnoDB はページ単位で表領域を管理します。delete または update 文を使用してデータを削除または更新する場合、これらの文はレコードの場所またはデータページを「再利用可能」としてマークするだけです。ディスクファイルのサイズは変わりません。これは、表領域の領域がすぐに再利用されないことを意味します。元の領域を再利用できない場合、断片化が発生し、ストレージ領域を消費します。
解決策: 詳細については、「MySQL の領域断片化の解決策」をご参照ください。
コマンドラインを使用したデフラグ:
optimize tableコマンドを使用して、表領域をデフラグします。DMS を使用したデータテーブルの最適化: RDS for MySQL インスタンスにログインします。DMS コンソールで、任意のテーブル名を右クリックし、[一括操作] を選択します。デフラグが必要なテーブルを選択し、 を選択します。
自動フラグメント再利用の有効化: RDS コンソールで、 に移動します。[自律機能スイッチ] をクリックします。自律機能を有効にした後、[最適化とスロットリング] タブに移動し、[自動フラグメント再利用] を有効にします。詳細については、「自動フラグメント再利用」をご参照ください。
システムファイルの蓄積によるストレージ不足
ほとんどの場合、大規模なシステムファイルは主に大きな undo ファイルによって引き起こされます。InnoDB テーブルに対するクエリが長時間実行され、クエリ中にテーブル内で大量のデータが更新されると、大量の undo データが生成され、ストレージを占有してストレージ容量が使い果たされます。データ損失を防ぐため、システムは自動的に RDS インスタンスをロックします。RDS インスタンスはロッキング状態になります。
解決策: 詳細については、「MySQL システムファイル蓄積の解決策」をご参照ください。
MySQL 8.0: システムは自動的に undo ファイルをクリーンアップします。
MySQL 5.7:
インスタンスの
innodb_undo_tablespacesパラメーターが2に設定されている場合、インスタンスは個別の undo 表領域を使用して undo データを保存し、このデータはクリーンアップできます。undo ファイルのサイズがinnodb_max_undo_log_sizeパラメーターの値を超え、ログがアクティブなトランザクションで不要になった場合、システムは undo ファイルに対してtruncate操作を実行して、大きすぎるファイルをクリーンアップし、領域を解放します。インスタンスの
innodb_undo_tablespacesパラメーターが0に設定されている場合、インスタンスは個別の undo 表領域を使用しません。undo ファイルはシステム表領域 ibdata1 に保存され、クリーンアップできません。これには 2 つの方法で対処できます:方法 1: 新しいインスタンスを作成し、DTS を使用してデータを移行します。詳細については、「RDS for MySQL コンソール操作 (データ移行)」をご参照ください。
方法 2: データベースのバージョンを MySQL 8.0 にアップグレードします。詳細については、「データベースのバージョンをアップグレードする」をご参照ください。
MySQL 5.5 および MySQL 5.6: undo ファイルのクリーンアップはサポートされていません。メジャーバージョンを MySQL 5.7 High-availability Edition インスタンスまたは MySQL 8.0 インスタンスにアップグレードする必要があります。アップグレード後、MySQL 5.7 は個別の undo 表領域を有効にすることで undo ファイルをクリーンアップできます。MySQL 8.0 は undo ファイルの自動クリーンアップをサポートしています。
個別の undo 表領域が有効になっていない MySQL 5.7 以前のインスタンス ( innodb_undo_tablespaces = 0 ) の場合、ibdata1 に書き込まれた undo データは、メジャーバージョンのアップグレード後も解放できません。アップグレード後、新しく生成された undo ログのみが個別の表領域に書き込まれ、自動クリーンアップをサポートします。元の ibdata1 ファイルが占有していた領域は再利用できません。
一般ログファイルの蓄積によるストレージ不足
ApsaraDB RDS for MySQL インスタンスで一般クエリログが有効になっている場合、ログファイルにはすべてのユーザー操作が記録されます。これには、クエリ、挿入、更新、削除など、すべての SQL 文の詳細が含まれます。インスタンスが高いトラフィックを処理する場合や、一般クエリログファイルが長期間クリーンアップされない場合、ファイルは継続的に増大します。迅速に対処しないと、ファイルは最終的にインスタンスのストレージ領域を使い果たしてしまいます。
解決策: 詳細については、「MySQL 一般ログファイル蓄積の解決策」をご参照ください。
一般ログ収集の無効化: 一般ログを無効にして (実行時パラメーターを OFF に設定)、新しいログが生成されないようにします。詳細については、「インスタンスパラメーターの設定」をご参照ください。
一般ログファイルの削除: RDS インスタンスにログインし、
TRUNCATE TABLE mysql.general_log;コマンドを実行して一般ログを削除します。通常のデータベース使用中は一般ログを無効にしておきます。デバッグやトラブルシューティングのために一時的にのみ有効にしてください。終了後は、速やかにログをクリーンアップし、この機能を無効にしてください。
ユーザーデータファイルの蓄積によるストレージ不足
ユーザーデータファイルは、定期的にクリーンアップされない場合、ストレージが満杯になる原因となります。テーブルスキーマで blob、text、長い varchar などのデータ型を使用すると、大量のストレージ領域も消費されます。データ損失を防ぐため、RDS for MySQL は自動的にインスタンスをロックします。インスタンスがロックされた後、書き込み操作は実行できません。
解決策: 詳細については、「RDS for MySQL データファイル蓄積の解決策」をご参照ください。
未使用データの削除:
dropまたはtruncateコマンドを使用して、未使用のデータをクリーンアップします。データの圧縮: ラージオブジェクトデータの場合、データベースに保存する前にデータを圧縮して、ストレージ領域の使用量を削減できます。
インデックスファイルの蓄積によるストレージ不足
データベースのインデックスは、ディスク上にファイルとして保存されます。非効率的なインデックス作成ポリシーを使用したり、多くのセカンダリインデックスを作成したりすると、インデックスファイルが蓄積され、大きくなりすぎる可能性があります。これにより、インスタンスのストレージ領域が不足する可能性があります。
解決策:
適切なフィールドにインデックスを作成する: 主キーインデックスに加えて、頻繁にクエリされるフィールド、ソートが必要なフィールド、またはテーブル結合でよく使用されるフィールドにインデックスを作成します。また、ディスク領域を節約するために、一列インデックスの代わりに複合インデックスを作成することを検討してください。
未使用のインデックスの削除: 使用されなくなった、または冗長なインデックスを削除して、ディスク領域を節約することを検討してください。また、データ構造を最適化して、セカンダリインデックスの数を減らします。
説明インデックスを削除すると、ブロッキングが発生する可能性があります。この操作はオフピーク時に実行してください。また、DMS の ロックフリーのスキーマ進化 機能を使用して、変更の影響を軽減することもできます。