Amazon Relational Database Service (Amazon RDS) の MySQL 上のデータベースインスタンスが、予想よりも多くのスペースを使用しています。その理由と、ディスクストレージを最適化する方法を教えてください。

Amazon CloudWatch の FreeStorageSpace メトリクスを使用すれば、RDS DB インスタンスで利用可能なストレージスペースをモニターできますが、このメトリクスでは DB インスタンスがストレージをどのように消費しているかはわかりません。

ストレージスペースを再利用するのに役立つ、いくつかの戦略があります。

OPTIMIZE TABLE の実行

テーブルが消費しているスペースの一部は実際に使用されているわけではありませんが、いずれにせよテーブルに割り当てられています。innodb_file_per_table を有効にすれば (デフォルトで有効になっています)、OPTIMIZE TABLE を使用して、スペースを再利用することができます。

断片化をチェックするには、次のようなクエリを使用することができるでしょう。

SELECT
	table_name,
	data_length,
	max_data_length,
	index_length,
	data_free
FROM
	information_schema.tables 
WHERE table_schema='schema_name'
;

data_free 列は、実際には使用されていないのにテーブルに割り当てられているフリースペースの量を明らかにしています。このスペースは、テーブルが RDS のデフォルトである innodb_file_per_table 構成設定に従って別個のテーブルスペース内に作成されているのであれば、OPTIMIZE TABLE によって再利用できます。

アプリケーションテーブルストレージの削減

どの程度のストレージが DB インスタンスのアプリケーションテーブルにより使用されているかを確認するには、次のようなクエリを実行できます。

SELECT 
	table_schema,
	SUM(data_length + index_length + data_free)/1024/1024 AS total_mb,
	SUM(data_length)/1024/1024 AS data_mb,
	SUM(index_length)/1024/1024 AS index_mb,
	SUM(data_free)/1024/1024 AS free_mb,
	COUNT(*) AS tables,
	CURDATE() AS today 
FROM 
	information_schema.tables
	GROUP BY table_schema
	ORDER BY 2 DESC
;

DB インスタンスで最も大きなアプリケーションテーブルを特定するには、次のようなクエリを実行できます。

SELECT 
	table_schema,
	table_name,
	(data_length + index_length + data_free)/1024/1024 AS total_mb,
	(data_length)/1024/1024 AS data_mb,
	(index_length)/1024/1024 AS index_mb,
	(data_free)/1024/1024 AS free_mb,
	CURDATE() AS today
FROM 
	information_schema.tables
	ORDER BY 3 DESC
;

注記: データベースに、768 バイトよりも長い可変長の列 (たとえば BLOB、TEXT、VARCHAR、または VARBINARY) を持つテーブルが含まれている場合には、個々のデータベースとテーブルが使用している合計ストレージを計算することはできません。

バイナリログストレージの削減

リードレプリカを追加すると、マスターインスタンスのバイナリログで追加のストレージが使用されるようになります。マスターインスタンスのバイナリログがどの程度のストレージを使用しているか確認するには、BinLogDiskUsage CloudWatch メトリクスを使用してください。大きく増加している場合には、1 つ以上のレプリカが同期していない可能性があります。詳細については、「Accessing MySQL Binary Logs (MySQL のバイナリログにアクセスする)」を参照してください。

一般ログとスロークエリログのストレージを削減する、または無効にする

一般ログとスロークエリログのパラメータを有効にすると、DB インスタンスはこれらのログを保存し始め、さらにこれらのログのバックアップを作成します。これらのファイルをローテーションさせ、ディスク使用量を制御する方法については、「mysql.rds_rotate_general_log」と「mysql.rds_rotate_slow_log」を参照してください。

注記: 潜在的なパフォーマンスとディスク使用量の問題を避けるため、トラブルシューティングの目的で実際に使用するのでなければ、一般ログとスロークエリログは無効にしておいてください。

InnoDB システムテーブルスペースのサイズを管理し、削減する

システムテーブルスペースには、InnoDB のデータディクショナリと取り消し用スペースが含まれており、最初の時点で10 MB のサイズがあります。スペースを割り当てると、ファイルは最小でもそのサイズになりますが、長期間のトランザクションがあると、利用可能なストレージはさらに多く消費されます。

デフォルトでは、RDS は innodb_file_per_table を 1 に設定します。これは、各々のテーブルスペースがそれ固有の .ibd ファイル内に保存されることを意味しています。関連するテーブルに対して再利用可能とマークされたスペースを回復するには、OPTIMIZE TABLE コマンドを使用して、テーブルごとのテーブルスペースファイルのサイズを小さくするか、またはテーブルをドロップします。

innodb_file_per_table0 に設定すると、すべてのテーブルがシステムテーブルスペースにも割り当てられます。テーブルまたはインデックスをドロップする、またはシステムテーブルスペースに割り当てられているテーブルのデータを削除するか切り詰めると、前には占有されていたスペースに再利用可能であるとのマークが付けられますが、このコマンドはファイルシステムのスペースを解放することはしません。

既存のシステムテーブルスペースをそのまま縮小することは不可能なので、現在のデータベースのデータをエクスポートしてから、データを新しいインスタンスにインポートすることになります。ダウンタイムを短くするために、新しい MySQL インスタンスは、ソース RDS のマスターインスタンスに従属するものとして設定してください。従属インスタンスがソース RDS のマスターインスタンスに同期したら、新しいインスタンスに切り替えます。手動によるレプリケーションの詳細については、「Amazon RDS の外部で実行される MySQL または MariaDB インスタンスとのレプリケーション」を参照してください。

注記: スナップショットからの復元や、リードレプリカの作成は、システムテーブルスペース内のスペースを回復する点では役に立ちません。どちらの方法でも、ソースのインスタンスストレージボリュームのスナップショットが使用されますが、これにはシステムテーブルスペースが含まれるからです。


このページは役に立ちましたか? はい | いいえ

AWS サポートナレッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2015 年 11 月 3 日

更新: 2018 年 4 月 2 日