Die Amazon RDS-Instanz verliert langsam freien Speicherplatz

Vor einiger Zeit verfügte der Server, auf dem meine Instanz ausgeführt wurde, über 20 GB EBS-Speicher. Dann wurden Festplattenspeicherfehler angezeigt, sodass ich sie auf 40 GB erhöhte. Andererseits fehlten Speicherfehler, so dass ich mich wieder auf 60 GB erhöhte. (Dies ist also eine 60 GB RDS-Instanz)

Hier sehen Sie die Tabelle mit dem freien Speicherplatz (MB) . Jedes Mal, wenn es hochschießt, füge ich mehr Speicherplatz hinzu.

Wenn ich diese Abfrage ausführe ..

SELECT CONCAT(table_schema, '.', table_name),
       CONCAT(ROUND(table_rows / 1000000, 2), 'M')                                    rows,
       CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G')                    DATA,
       CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G')                   idx,
       CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size,
       ROUND(index_length / data_length, 2)                                           idxfrac
FROM   information_schema.TABLES
ORDER  BY data_length + index_length DESC
LIMIT  10;

Ich bekomme folgende Antwort ...

Nichts zeichnet sich dadurch aus, dass es viel Platz einnimmt.

Wenn ich dann renne

select table_schema, CONCAT(ROUND( sum((data_length+index_length)/1024/1024)/1024, 2), 'G') AS MB from information_schema.tables group by 1;

Ich kann sehen, dass der größte Tisch ungefähr 10 GB hat. (Dies beinhaltet data_length und index_length)

Mein nächster Gedanke ist, dass der langsame Speicherplatz general_log oder langsame Abfrageprotokolle ist, die auf die Festplatte schreiben ...

Wenn ich die Parametergruppen auf meiner RDS-Instanz überprüfe, kann ich sehen, dass die Protokollierung deaktiviert ist.

Hat jemand eine Idee, warum mein RDS-Server langsam Speicherplatz verliert?

AKTUALISIEREN:

Ich habe Hilfe von den freundlichen Leuten auf #mysql bekommen

Nach dem Rennen

show global variables like 'log_bin';

Es war klar, dass binäre Protokolle aktiviert waren.

Ich rannte dann

show binary logs und hatte 41674+ Protokolle.

Beim Durchblättern meiner Protokolle konnte ich feststellen, dass eine der Dateigrößen 2064636 war

Ich habe dann versucht, alle Binärprotokolle bis zu dieser Änderungsprotokolldatei zu löschen.

purge binary logs to "mysql-bin-changelog.152193"

RDS bietet jedoch nicht File_privoder Super_privfür den Hauptbenutzer.

Ich würde gerne denken, dass hier der Speicherplatz verschwunden ist. 2064636 ist jedoch nur etwa 2 MB groß ... Also zurück zum Zeichenbrett?

Sie können die Aufbewahrungsdauer Ihres Binärprotokolls mit dem folgenden Befehl unter MySQL überprüfen:

mysql> call mysql.rds_show_configuration;

Verwenden Sie den folgenden Befehl, um die Aufbewahrungsdauer auf 1 Tag festzulegen:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

Dies bedeutet, dass MySQL-Dienste jeden Tag das Binärprotokoll löschen.

Außerdem, das Binärprotokoll, ich denke, Sie können die Einstellung von innodb_file_per_table überprüfen , werden alle Daten in der ibdata-Datei gespeichert, wenn es mit "0" zugewiesen wird.

Ich empfehle Ihnen, die Option "1" zuzuweisen, damit Ihre Tabelle separat gespeichert wird und Sie Ihren genutzten Speicherplatz zurückfordern können, indem Sie:

mysql> OPTIMIZE TABLE <table_name>

Überprüfen Sie die folgenden Referenzlinks , um festzustellen, ob sie Ihr Problem widerspiegeln:
So stellen Sie Speicherplatz in InnoDB wieder her, wenn innodb_file_per_table aktiviert ist

Warum wächst die ibdata1-Datei in MySQL kontinuierlich?

Eine weitere Sache, laut der Website, werden Sie eine schnell wachsende ibdata1-Datei haben, weil Sie eine lange laufende Transaktion haben. Versuchen Sie, sie so schnell wie möglich festzuschreiben, um zu vermeiden, dass eine Systemwiederherstellung durchgeführt wird, um Speicherplatz zurückzugewinnen.

Ich denke, der verlorene freie Speicherplatz befindet sich in den Tablespace-Dateien der InnoDB-Speicher-Engine. Nachdem ich mit dem AWS-Support gesprochen hatte, schlugen sie mir vor, sie neu zu erstellen, indem ich eine neue Instanz einrichtete, indem ich alle Daten speicherte und in diese neue Instanz importierte und dann wechselte. Das Erstellen eines Lesereplikats funktioniert in diesem Fall nicht, da Lesereplikate beim Erstellen denselben Speicher mit der Masterinstanz verwenden.

In diesem Prozess musste ich die Replikation manuell einrichten. Ich folgte der Anleitung hier ( http://www.ruempler.eu/2014/06/15/external-non-mysql-slaves-with-rds-reloaded/ ) und erstellte ein Skript, um diesen Prozess zu automatisieren. Sie finden es unter:

https://github.com/cenk/darbe