Aurora MySQL で DELETE したレコードの領域を解放するにはどうしたらいいですか
困っていた内容
Amazon Aurora MySQL で大量のレコードを DELETE しましたが、クラスターボリュームの使用量が縮小されず、ストレージが解放されません。
DELETE 後にディスク領域を縮小するには、どのような方法があるのでしょうか。
どう対応すればいいの?
Aurora MySQL のクラスターボリュームは動的にサイズが変化しますが、DELETE ステートメントによる行削除では領域は解放されません。
DELETE で削除した行の領域を物理的に解放するには、OPTIMIZE TABLE を実行する必要があります。
動的サイズ変更が適用される操作
Aurora のクラスターボリュームは、テーブルやデータベースを物理的に削除またはサイズ変更する操作に対して動的に縮小されます。
動的サイズ変更は、クラスターボリューム内のテーブルスペースを物理的に削除またはサイズ変更するオペレーションに適用されます。つまり、DROP TABLE、DROP DATABASE、TRUNCATE TABLE、および ALTER TABLE ... DROP PARTITION などの SQL ステートメントに対し適用されます。DELETE ステートメントを使用した行の削除には適用されません。テーブルから多数の行を削除する場合は、Aurora MySQL OPTIMIZE TABLE ステートメントを実行するか、後で Aurora PostgreSQL pg_repack エクステンションを使用して、テーブルを再編成し、クラスターボリュームのサイズを動的に変更できます。
引用にあるとおり、DROP TABLE、DROP DATABASE、TRUNCATE TABLE、ALTER TABLE ... DROP PARTITION のように、テーブルやパーティション単位でまるごと削除する操作であれば、クラスターボリュームのサイズも自動的に縮小されます。
なお、動的サイズ変更が利用できるのは Aurora MySQL バージョン 3 のすべてのサポート対象バージョンと、バージョン 2 (MySQL 5.7 互換) の 2.11 以降です。
これより古いバージョンでは DROP TABLE 等を実行してもクラスターボリュームは縮小されないため、ご利用のバージョンを事前にご確認ください。
一方で、DELETE ステートメントによる行単位の削除では、削除された領域はテーブル内で再利用されるだけで、クラスターボリューム全体のサイズは縮小されません。
OPTIMIZE TABLE 実行時の注意点
OPTIMIZE TABLE はテーブルを再編成する操作のため、対象テーブルのサイズや負荷状況によっては相応の時間を要します。
そのため、本番環境で実行される際には、事前に検証環境で所要時間や影響を確認しておくことをおすすめします。
クラスターボリュームの使用状況を確認する
クラスターボリュームのサイズ推移は、CloudWatch の VolumeBytesUsed および AuroraVolumeBytesLeftTotal メトリクスで確認いただけます。
OPTIMIZE TABLE の実行前後でこれらのメトリクスの推移を比較することで、実際にクラスターボリュームが縮小されたかをご確認いただけます。
参考情報
