MySQL: Buchungen autom. löschen, wenn Person oder Termin gelöscht wird

[Raketenwilli]

Nein, sowas habe ich weder behauptet noch vormachen wollen. Ich wollte nur mal eine „ausreichend große“ Datenbank in die Runde werfen, damit jede(r) ein Bild machen kann.

Etwa so:

1. Einlesen eines Dumps:

ll -h flughafendb_large_de.sql 
-rw-rw-r--+ 1 fastix fastix 2,2G Feb 28 00:45 flughafendb_large_de.sql

time mysql test < flughafendb_large_de.sql 

real	374m19,278s
user	1m9,086s
sys	0m1,596s

Das mag ein langsamer Rechner mit einem „Intel(R) Celeron(R) J4125 CPU @ 2.00GHz“ (mein NAS) sein, man kann es aber drehen und wenden wie man will: 6 Stunden für das Recovery wären inakzeptabel. Allerdings vermute ich, dass da noch Optimierungspotential drin steckt: Ich habe nämlich einen Dump, der mit mysql 5.7.6 gemacht wurde, mit mariadb eingelesen.

2. Herstellen eines Dumps

mysqldump --opt --lock-tables test | gzip -c > /tmp/test.sql.gz

real	4m4,907s
user	4m1,635s
sys	0m1,943s

Das geht also freilich deutlich schneller. Nur sorgt das --lock-tables ebenfalls für eine faktische Downtime wenn man nicht eine Datenbank betreibt, in welche selten (und nur auf besondere Veranlassung des Betreibers) geschrieben wird.

Wie schon geschrieben: Mein Favorit fürs Desaster-Recovery ist „kein Desaster-Recovery“ sondern ein Cluster. Der Dump oder jede andere Art von Backup (z.B. via binlog) ist toll, wenn es darum geht bestimmte Zustände periodisch zu sichern um bei Unfällen oder absichtlicher Zerstörung von Daten in der Datenbank einen früheren Zustand wieder herzustellen.

• https://mariadb.com/kb/en/backing-up-and-restoring-databases/
• https://mariadb.com/docs/server/deploy/community-cluster-cs10-6/