Warum nehmen meine "verwendeten Volumenbytes" in meinem Amazon Aurora-Cluster immer zu?


10

Ich habe einen Amazon (AWS) Aurora DB-Cluster, der jeden Tag [Billed] Volume Bytes Usedzunimmt.

VolumeBytesUsed CloudWatch-Metrik im Zeitverlauf

Ich habe die Größe aller meiner Tabellen (in allen meinen Datenbanken in diesem Cluster) anhand der folgenden INFORMATION_SCHEMA.TABLESTabelle überprüft :

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         |
+------------+-------------+------------+

Gesamt: 53 GB

Warum werden mir zu diesem Zeitpunkt fast 75 GB in Rechnung gestellt?

Ich verstehe, dass bereitgestellter Speicherplatz niemals freigegeben werden kann, genauso wie die ibdata-Dateien auf einem normalen MySQL-Server niemals verkleinert werden können. Das ist ok für mich. Dies ist dokumentiert und akzeptabel.

Mein Problem ist, dass der mir in Rechnung gestellte Platz von Tag zu Tag größer wird. Und ich bin sicher, dass ich vorübergehend NICHT 75 GB Speicherplatz benutze. Wenn ich so etwas machen würde, würde ich verstehen. Es ist, als würde der Speicherplatz, den ich freigebe, indem ich Zeilen aus meinen Tabellen lösche oder Tabellen lösche oder sogar Datenbanken lösche, nie wieder verwendet.

Ich habe den AWS (Premium) -Support mehrmals kontaktiert und konnte nie eine gute Erklärung dafür erhalten.
Ich habe Vorschläge erhalten, OPTIMIZE TABLEdie Tabellen auszuführen , für die es viele gibt free_space(pro INFORMATION_SCHEMA.TABLESTabelle), oder die Länge des InnoDB-Verlaufs zu überprüfen, um sicherzustellen, dass gelöschte Daten nicht noch im Rollback-Segment gespeichert sind (Ref: MVCC ). und starten Sie die Instanz (en) neu, um sicherzustellen, dass das Rollback-Segment geleert wird.
Keiner von denen half.

Antworten:


17

Hier spielen mehrere Dinge eine Rolle ...

  1. Jede Tabelle wird in einem eigenen Tabellenbereich gespeichert

    Standardmäßig wird die Parametergruppe für Aurora-Cluster (benannt default.aurora5.6) definiert innodb_file_per_table = ON. Das bedeutet, dass jede Tabelle in einer separaten Datei im Aurora-Speichercluster gespeichert wird. Mit dieser Abfrage können Sie sehen, welcher Tabellenbereich für jede Ihrer Tabellen verwendet wird:

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    Anmerkung: Ich habe nicht versucht , zu ändern innodb_file_per_tablezu OFF. Vielleicht würde das helfen ..?

  2. Durch das Löschen von Tablespaces freigegebener Speicherplatz wird NICHT wiederverwendet

    Zitieren des AWS Premium-Supports:

    Aufgrund des einzigartigen Designs der Aurora Storage Engine zur Erhöhung der Leistung und Fehlertoleranz verfügt Aurora nicht über die Funktionalität, Tabellenbereiche pro Datei auf die gleiche Weise wie Standard-MySQL zu defragmentieren.

    Derzeit hat Aurora leider keine Möglichkeit, Tablespaces wie bei MySQL zu verkleinern, und der gesamte fragmentierte Speicherplatz wird in Rechnung gestellt, da er in VolumeBytesUsed enthalten ist.
    Der Grund dafür, dass Aurora den Speicherplatz einer abgelegten Tabelle nicht auf die gleiche Weise wie Standard-MySQL zurückfordern kann, besteht darin, dass die Daten für die Tabelle auf eine völlig andere Weise als in einer Standard-MySQL-Datenbank mit einem einzelnen Speichervolumen gespeichert werden.

    Wenn Sie eine Tabelle oder Zeile in Aurora ablegen, wird der Speicherplatz auf dem Auroras-Cluster-Volume aufgrund dieses komplizierten Designs nicht zurückgefordert.
    Diese Unfähigkeit, kleine Mengen an Speicherplatz zurückzugewinnen, ist ein Opfer, das erzielt wurde, um die zusätzlichen Leistungssteigerungen des Auroras-Cluster-Speichervolumens und die stark verbesserte Fehlertoleranz von Aurora zu erzielen.

    Es gibt jedoch eine unklare Möglichkeit, einen Teil dieses verschwendeten Speicherplatzes wiederzuverwenden ...
    Zitieren Sie erneut den AWS Premium-Support:

    Sobald Ihr Gesamtdatensatz eine bestimmte Größe (ca. 160 GB) überschreitet, können Sie Speicherplatz in 160-GB-Blöcken zur Wiederverwendung zurückfordern, z. B. wenn Ihr Aurora-Cluster-Volume 400 GB und DROP 160 GB oder mehr Tabellen enthält, die Aurora dann verwenden kann 160 GB Daten werden automatisch wiederverwendet. Es kann jedoch langsam sein, diesen Speicherplatz zurückzugewinnen.
    Der Grund für die große Datenmenge, die sofort freigegeben werden muss, ist das einzigartige Design von Auroras als DB-Engine im Unternehmensmaßstab im Gegensatz zu Standard-MySQL, das in diesem Maßstab nicht verwendet werden kann.

  3. OPTIMIEREN SIE TABELLE ist böse!

    Da Aurora auf MySQL 5.6 basiert, OPTIMIZE TABLEwird es zugeordnet ALTER TABLE ... FORCE, wodurch die Tabelle neu erstellt wird, um die Indexstatistik zu aktualisieren und nicht verwendeten Speicherplatz im Clustered-Index freizugeben. Zusammen mit innodb_file_per_table = ONbedeutet dies, dass beim Ausführen einer OPTIMIZE TABLEeine neue Tablespace-Datei erstellt und die alte gelöscht wird. Da durch das Löschen einer Tablespace-Datei der verwendete Speicher nicht freigegeben wird, OPTIMIZE TABLEwird immer mehr Speicher bereitgestellt. Autsch!

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

  4. Temporäre Tabellen verwenden

    Standardmäßig wird die Parametergruppe für Aurora-Instanzen (benannt default.aurora5.6) definiert default_tmp_storage_engine = InnoDB. Das bedeutet, dass jedes Mal, wenn ich eine TEMPORARYTabelle erstelle , diese zusammen mit all meinen regulären Tabellen im Aurora-Speichercluster gespeichert wird . Dies bedeutet, dass neuer Speicherplatz für diese Tabellen bereitgestellt wird, wodurch sich das Gesamtvolumen von VolumeBytesUsed erhöht.
    Die Lösung hierfür ist einfach genug: Ändern Sie den default_tmp_storage_engineParameterwert in MyISAM. Dadurch wird Aurora gezwungen, die TEMPORARYTabellen im lokalen Speicher der Instanz zu erstellen .
    Bemerkenswert: Der lokale Speicher der Instanzen ist begrenzt. In der Free Local StorageMetrik in CloudWatch können Sie sehen, wie viel Speicherplatz Ihre Instanzen haben. Größere (kostspieligere) Instanzen verfügen über mehr lokalen Speicher.

    Ref: noch keine; In der aktuellen Amazon Aurora-Dokumentation wird dies nicht erwähnt. Ich habe das AWS-Supportteam gebeten, die Dokumentation zu aktualisieren, und werde meine Antwort aktualisieren, wenn dies der Fall ist.


1
Dies ist eine großartige Antwort, und ja , das sind einige wichtige Vorbehalte. Ich bin froh, dass ich das gesehen habe.
Ceejayoz

Das Gleiche gilt. Es wurde festgestellt, dass ein DB-Server bis zu 300 GB groß war, für eine Datenbank mit einer von MySQL gemeldeten Größe von 54 GB. Wenn der Speicherplatz nie zurückgefordert wird, ist dies ein gutes Beispiel dafür, was passiert, wenn Sie viele häufig geschriebene Tabellen haben ( zB Protokolltabellen, Indextabellen usw.).
Geerlingguy

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.