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.
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;
Referenz: MySQL-Dokumentation
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
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/%';
Hier sind die Schritte zum Freigeben von Speicherplatz:
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
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!