web-dev-qa-db-ja.com

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

私は Amazon（AWS）Aurora DBクラスターを使用しており、その[Billed] Volume Bytes Usedは日々増加しています。

VolumeBytesUsed CloudWatch metric over time

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（プレミアム）サポートに何度も問い合わせましたが、その理由については十分な説明がありませんでした。
たくさんのOPTIMIZE TABLEが存在するテーブルでfree_spaceを実行する（INFORMATION_SCHEMA.TABLESテーブルごとに）、またはInnoDB履歴の長さを確認する提案を受けました、削除されたデータがまだロールバックセグメントに保持されていないことを確認し（参照： [〜＃〜] mvcc [〜＃〜] ）、インスタンスを再起動してロールバックを確認しますセグメントは空です。
それらのどれも助けませんでした。

amazon-web-servicesamazon-rds
11
Guillaume Boudreau

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

  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があり、DROP 160 GB以上のテーブルがある場合、Auroraは160 GBのデータを自動的に再利用できます。ただし、このスペースを再利用するには時間がかかる場合があります。
    一度に解放する必要がある大量のデータの理由は、この規模では使用できない標準のMySQLとは異なり、エンタープライズ規模のDBエンジンとしてのAuroras独自の設計によるものです。

  3. OPTIMIZE TABLE is evil！

    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テーブルを作成するたびに、すべてのregularテーブルと共に、Auroraストレージクラスターに保存されます。つまり、これらのテーブルを保持するために新しいスペースがプロビジョニングされ、VolumeBytesUsedの合計が増加します。
    この解決策は非常に単純です。default_tmp_storage_engineパラメータ値をMyISAMに変更します。これにより、AuroraはインスタンスのローカルストレージにTEMPORARYテーブルを作成します。
    注意：インスタンスのローカルストレージは制限されています。 CloudWatchのFree Local Storageメトリックを参照して、インスタンスにどれだけのストレージがあるかを確認してください。大きい（コストのかかる）インスタンスには、より多くのローカルストレージがあります。

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

18
Guillaume Boudreau

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

0
Arinjay