Das deutsche Python-Forum

Hallo,

ungefähr um halb 12 nachts setzt das Forum aus mit MySQL Problemen. Etwas später geht’s wieder. Beobachtet ihr das auch?

23.25 Uhr bis 23.46 Uhr zum Beispiel?

Das ist der täglich DB Dump. Aufrgund der Größe der Forums DB (~11 GB) wird das Zeitfenster immer größer das der Dump benötigt.
Ich sehe das Problem auch im Monitoring jeden Tag, Habe mich aber noch nicht wirklich um ein Lösung gekümmert.
Ein Gedanke von mir ist, den Dump nicht lokal auf die Platten zu schreiben, sondern auf eine RamDisk. Das sollte den IO Peak reduzieren.
Nimmt aber auch enorm viel RAM weg, der nicht unbedingt frei ist.
Einfach den Dump etwas später zu machen, ist keine Lösung, da er dann mit den anderen Backup Diensten kollidiert und das Problem zeitlich nur verschiebt.

Im Moment kann ich mich vermutlich nur für den täglichen Ausfall entschuldigen.

Muss die Datenbank offline sein, um sie zu sichern?

Sie ist nicht direkt offline.
mysqldump setzt einen LOCK auf die aktuelle DB um die Integrität der Daten und Prozesse zu gewährleisten.
Simple Lösung wäre das Flag --single-transaction mit in das Kommando auf zu nehmen. Ich habe aber keine Ahnung welche Auswirkung das Flag auf den Rest der Backups auswirkt.

Ein besser Lösung wäre es, die DB einfach mal zu säubern und in der Größe zu reduzieren. Das würde die Dump Zeit deutlich mehr beschleunigen.

Damaskus hat geschrieben: ↑Samstag 11. April 2020, 07:10 Einfach den Dump etwas später zu machen, ist keine Lösung, da er dann mit den anderen Backup Diensten kollidiert und das Problem zeitlich nur verschiebt.

Im Moment kann ich mich vermutlich nur für den täglichen Ausfall entschuldigen.

Falls der Dump und die Backup-Dienste per Cron-Job gestartet und Kollisionen über einen zeitlichen Puffer vermieden werden, könnte es auch eine Überlegung wert sein, den gesamten Ablauf auf Systemd (Timer) Units umzustellen. Der Vorteil daran ist, dass man damit echte Abhängigkeiten (und auch weitere Logiken) zwischen Diensten definieren kann. Der zeitliche Puffer (der ja gerne recht großzügig gewählt wird) entfällt dadurch und das Backup und/oder die anderen Diensten können unmittelbar gestartet werden, wenn alle Abhängigkeiten erfüllt sind, anstatt zu warten. Durch die zeitliche Ersparnis kann man es dann vielleicht doch nach hinten verschieben.

Das Backup kurz erklärt:
Es geht um zig Server die alle identisch in einem zugewiesenen Zeitslot gesichert werden um das IO der Backup Server nicht zu überlasten.
Die jeweiligen Aufgaben werden von extern getriggert um genau diese zeitlichen Puffer zu beseitigen.
Anforderung war es, DB und Dateisystem weitesgehend zueinander kompatibel halten. Es bringt nichts eine Datenbank um 23 Uhr zu sichern und das zugehörige Dateisystem um 5 Uhr (als Beispiel).
Das Forum ist in diesem Setup echt ein Sonderfall, da es keine andere DB auf einem Shared Hosting Server auf diese Größe bringt (zumindest bei uns).

Erstmal danke fuer die Erklaerung. Es waere natuerlich nett, wenn man den Dump um 5 Uhr morgends oder aehnliches machen kann, aber wichtiger ist mir, dass es kein Zeichen eines Problems ist. Und das scheint es ja nicht zu sein.

11 GiB ist schon heftig. Werden Bilder auch in der DB gespeichert oder wieso ist die so groß?

Das sind umgerechnet 32 KiB pro Beitrag.

Ups, gar nicht gesehen, dass es schon ~355.000 Beiträge sind.

Ich habe heute eine Änderung im Backup Service ausgerollt und auch den MariaDB Server etwas optimiert.
Somit dürfte der Blackout hoffentlich nicht mehr auftreten. Rückmeldungen wären schön.

Ich achte drauf! Zeit ist aber gleich geblieben?