Heim  >  Artikel  >  Datenbank  >  Optimierung des Aurora MySQL-Speichers durch Löschen unnötiger Daten

Optimierung des Aurora MySQL-Speichers durch Löschen unnötiger Daten

DDD
DDDOriginal
2024-09-14 10:18:17861Durchsuche

Eine Tabelle in unserer Aurora MySQL-Datenbank verbrauchte etwa 80 % (etwa 400 GB) des Gesamtspeichers. Da wir ältere Daten als CSV-Dateien archivieren konnten, haben wir uns entschieden, alte Datensätze zu löschen und den Speicherplatz freizugeben.

Ich dachte zunächst, dass das Löschen der Datensätze den Speicherplatz freigeben würde, aber es stellte sich als komplizierter als erwartet heraus. Deshalb dokumentiere ich die detaillierten Schritte zum späteren Nachschlagen.

Überprüfen der Tabellenspeichernutzung

Sie können die Größe jeder .ibd-Datei mit der folgenden Abfrage überprüfen:

SELECT file_name, ROUND(SUM(total_extents * extent_size)/1024/1024/1024,2) AS "TableSizeinGB" 
FROM information_schema.files 
GROUP BY file_name 
ORDER BY total_extents DESC;

Optimizing Aurora MySQL Storage by Deleting Unnecessary Data

Referenz: MySQL-Dokumentation

Wichtiger Hinweis

AWS re:Post empfahl die folgende Abfrage, um die Tabellengröße zu überprüfen, aber die Ergebnisse für die Zieltabelle waren im Vergleich zur ersten Abfrage etwa 150 GB kleiner.

SELECT table_schema "DB Name", table_name, 
       (data_length + index_length)/1024/1024/1024 AS "TableSizeinGB" 
FROM information_schema.tables 
WHERE table_schema = 'database_name';

Als ich den AWS-Support konsultierte, bestätigten sie, dass information_schema.tables nur statistische Werte bereitstellt, die oft ungenau sind. Sie empfahlen die Verwendung von information_schema.files, um genaue Daten zu erhalten.

Die Informationen zur Tabellengröße (390 GB) wurden aus information_schema.tables abgerufen und da es sich um statistische Daten handelt, sind sie wahrscheinlich ungenau. In Zukunft empfehlen wir die Verwendung von information_schema.files zum Abrufen von Informationen zur Tabellengröße.

Referenz: AWS re:Post

Überprüfen der Datenbankspeichernutzung

Die folgende Abfrage überprüft die gesamte Datenbanknutzung. Aus Gründen der Genauigkeit wird dabei auch information_schema.files verwendet.

SELECT file_name, ROUND(SUM(total_extents * extent_size)/1024/1024/1024,2) AS "TableSizeinGB" 
FROM information_schema.files 
WHERE file_name LIKE '%/database_name/%';

Schritte zum Freigeben von Datenbankspeicher

Hier sind die Schritte zum Freigeben von Speicherplatz:

  1. Alte Datensätze löschen.
  2. Ändern Sie bei Bedarf die Instanzklasse.
  3. Führen Sie OPTIMIZE TABLE ; aus.

Durch das einfache Löschen von Datensätzen wird kein Speicherplatz freigegeben. Sie müssen OPTIMIZE TABLE ausführen, um den Speicherplatz freizugeben.

Zusätzlich werden während der Operation OPTIMIZE TABLE (oder ALTER TABLE ... FORCE) temporäre Zwischentabellendateien erstellt. In Aurora werden diese temporären Dateien im lokalen Speicher gespeichert. Die Menge des lokalen Speichers hängt von der Instanzklasse ab. In meinem Fall verfügt die db.r6g.xlarge-Instanz nur über 80 GB lokalen Speicher, was für die Größe der gelöschten Datensätze nicht ausreicht. Also habe ich vorübergehend auf db.r6g.8xlarge (640 GB) hochskaliert.

Referenz: Tabelle optimieren

Referenz: Tabelle ändern

Referenz: InnoDB Online DDL-Speicherplatzanforderungen

Referenz: Aurora MySQL Temporary Storage

Vorsicht bei der Verwendung von OPTIMIZE TABLE

Nachdem etwa 250 GB Datensätze gelöscht wurden, dauerte die Ausführung von OPTIMIZE TABLE etwa 130 Minuten (etwa 2 Stunden). Da OPTIMIZE TABLE die Tabelle sperrt, müssen Sie möglicherweise eine Ausfallzeit einplanen oder diesen Vorgang außerhalb der Hauptverkehrszeiten ausführen. Zur Veranschaulichung: Das Löschen aller Datensätze hat insgesamt etwa 15 Stunden gedauert, was ich über mehrere Tage verteilt habe.

Das obige ist der detaillierte Inhalt vonOptimierung des Aurora MySQL-Speichers durch Löschen unnötiger Daten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn