Amazon Auroraクラスターで「使用ボリュームバイト」が常に増加するのはなぜですか？

私はAmazon（AWS）Aurora DBクラスターを持っていますが、毎日[Billed] Volume Bytes Used増加しています。

テーブルを使用して（そのクラスター上のすべてのデータベース内の）すべてのテーブルのサイズを確認しましたINFORMATION_SCHEMA.TABLES。

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

合計：53GB

それで、なぜ私が現在ほぼ75GBを請求されているのですか？

通常のMySQLサーバー上のibdataファイルが縮小できないのと同じように、プロビジョニングされたスペースを解放できないことを理解しています。私はそれで大丈夫です。これは文書化されており、許容されます。

私の問題は、毎日、請求されるスペースが増えることです。そして、私は一時的に75GBのスペースを使用していないと確信しています。そのようなことをしたら、理解できます。テーブルから行を削除したり、テーブルを削除したり、データベースを削除したりすることで解放している記憶域が再利用されることはないかのようです。

AWS（プレミアム）サポートに何度も問い合わせたことがありますが、その理由について十分な説明がありませんでした。（テーブルごとに）たくさんあるテーブルで
実行するか、またはInnoDB履歴の長さをチェックして、削除されたデータがロールバックセグメントにまだ保持されていないことを確認するための提案を受けました（参照：MVCC） 、インスタンスを再起動して、ロールバックセグメントが空であることを確認します。 それらのどれも助けませんでした。OPTIMIZE TABLEfree_spaceINFORMATION_SCHEMA.TABLES

ここでプレイしているものは複数あります...

1. 各テーブルは独自のテーブルスペースに保存されます

   デフォルトでは、Auroraクラスター（名前付きdefault.aurora5.6）のパラメーターグループはを定義しますinnodb_file_per_table = ON。つまり、各テーブルは、Auroraストレージクラスター上の個別のファイルに保存されます。次のクエリを使用して、各テーブルにどのテーブルスペースが使用されているかを確認できます。

   SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

   注：に変更innodb_file_per_tableを試みていませんOFF。多分それは助けになるだろう..？

2. テーブルスペースを削除して解放されたストレージスペースは再利用されません

   AWSプレミアムサポートの引用：

   パフォーマンスとフォールトトレランスを向上させるAuroraストレージエンジンの独自の設計により、Auroraには、標準のMySQLと同じようにファイルごとのテーブルスペースをデフラグする機能がありません。

   現在、Auroraには残念ながら標準のMySQLのようにテーブルスペースを縮小する方法がなく、VolumeBytesUsedに含まれているため、すべての断片化されたスペースが課金されます。
   Auroraが標準のMySQLと同じ方法で削除されたテーブルのスペースを再利用できないのは、テーブルのデータが単一のストレージボリュームを持つ標準のMySQLデータベースとはまったく異なる方法で格納されるためです。

   Auroraにテーブルまたは行をドロップすると、この複雑な設計のため、Aurorasクラスターボリュームでスペースが再利用されません。
   少量のストレージスペースを再利用できないため、Aurorasクラスターストレージボリュームのパフォーマンスがさらに向上し、Auroraのフォールトトレランスが大幅に改善されました。

   しかし、その無駄なスペースの一部を再利用するあいまいな方法があります...
   繰り返しますが、AWSプレミアムサポートを引用します。

   データセットの合計が特定のサイズ（約160 GB）を超えると、160 GBブロックのスペースを再利用できるようになります。たとえば、Auroraクラスターボリュームに400 GBがあり、160 GB以上のテーブルをドロップすると、Auroraは160 GBのデータを自動的に再利用します。ただし、このスペースを再利用するには時間がかかる場合があります。
   大量のデータを一度に解放する必要があるのは、この規模では使用できない標準のMySQLとは異なり、エンタープライズ規模のDBエンジンとしてのAuroras独自の設計によるものです。

3. OPTIMIZE TABLEは悪です！

   AuroraはMySQL 5.6に基づいているため、OPTIMIZE TABLEにマッピングされALTER TABLE ... FORCE、テーブルを再構築してインデックス統計を更新し、クラスター化インデックスの未使用スペースを解放します。と効果的には、と一緒innodb_file_per_table = ONに実行するとOPTIMIZE TABLE、新しいテーブルスペースファイルが作成され、古いファイルが削除されます。テーブルスペースファイルを削除しても、使用していたストレージは解放されないOPTIMIZE TABLEため、常により多くのストレージがプロビジョニングされます。痛い！

   参照：https : //dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

4. 一時テーブルの使用

   デフォルトでは、Auroraインスタンス（名前付きdefault.aurora5.6）のパラメーターグループはを定義しますdefault_tmp_storage_engine = InnoDB。つまり、TEMPORARYテーブルを作成するたびに、すべての通常のテーブルと共に、Auroraストレージクラスターに保存されます。つまり、これらのテーブルを保持するために新しいスペースがプロビジョニングされ、VolumeBytesUsedの合計が増加します。
   この解決策は非常に単純です。default_tmp_storage_engineパラメーター値をに変更しますMyISAM。これにより、Aurora TEMPORARYはインスタンスのローカルストレージにテーブルを作成します。
   注意：インスタンスのローカルストレージは制限されています。Free Local StorageCloudWatch のメトリックを参照して、インスタンスにどれだけのストレージがあるかを確認してください。大きい（コストのかかる）インスタンスには、より多くのローカルストレージがあります。

   参照：まだありません。現在のAmazon Auroraのドキュメントではこれについて言及されていません。AWSサポートチームにドキュメントの更新を依頼しました。更新があった場合は更新します。

テーブルやパーティションを削除するなどしてAuroraデータを削除しても、割り当てられたスペース全体は同じままです。空き容量は、将来データ量が増えると自動的に再利用されます。 https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html