AWSは12月5日、同社のブログでAmazon Aurora MySQLのストレージ使用構造と、その管理・監視方法について解説した。Aurora MySQLは高性能なリレーショナルデータベースサービスで、MySQLと互換性がある。Auroraのストレージはクラスターボリュームストレージとローカルストレージの2種類に分かれる。
クラスターボリュームストレージは複数のアベイラビリティーゾーンに分散され、耐障害性と高可用性を実現する。ここにはInnoDBテーブル、インデックス、バイナリログなどの永続的データが保存される。一方、ローカルストレージは一時ファイルやエンジンログの保存に用いられる。
Aurora MySQLではInnoDBストレージエンジンのみをサポートし、“innodb_file_per_table”がONの場合はテーブルごとにテーブルスペースが割り当てられ、空き領域も自動的に回収される。テーブルスペースごとの容量確認にはINFORMATION_SCHEMA.FILESテーブルが有効だ。INFORMATION_SCHEMA.TABLESではキャッシュ統計値が含まれるため、リアルタイムな容量確認にはFILESテーブルの利用が推奨される。
また、テーブルやバージョンによる扱いの違いについても述べられている。Aurora MySQL 2（MySQL 5.7互換）は内部・外部で一時的に利用するテーブルの保存場所に違いがあり、クラスターボリュームやローカルストレージが活用される。Aurora 3（MySQL 8.0互換）ではTempTableストレージエンジンなど新たな制御パラメータが追加され、管理が容易となった。
加えて、バイナリログとリレーログに関連し、保持期間やレプリケーションの状態がストレージ消費に影響する。不要なリレーログの容量解放やCloudWatchメトリクスによる監視方法も解説されている。
Auroraクローン利用時のストレージ計上や、クローンの削除による課金の仕組みにも注意が必要だ。
この記事は参考になりましたか？
- この記事の著者
-
CodeZine編集部（コードジンヘンシュウブ）
CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
