Datenbank-Knieschuß

Irgendwann mußte es ja mal passieren. Vorhin war es soweit. Aber der Reihe nach: Wie die meisten meiner Leser wissen, betreue ich ja nebenher ein relativ gut besuchtes Webforum. Leider bietet das dort eingesetzte Forumsskript nicht die Möglichkeit, einzelne Postings zwischen Threads zu verschieben – was durchaus sinnvoll ist, wenn eine Diskussion mal völlig vom eigentlichen Thema abgleitet. Daher erledige ich das Verschieben von Postings immer mittels phpMyAdmin direkt in der zugrunde liegenden Datenbank. Das ist zwar relativ lästig, weil die Autoren des Forumsskripts offenkundig noch nie etwas von Daten-Normalisierung gehört haben, aber grundsätzlich nicht kompliziert und von mir auch schon oft durchgeführt.

Genau diese Posting-Verschiebung wollte ich vorhin auch machen und als ich damit fast fertig war, noch schnell ein einzelnes, „überzähliges“ Posting löschen. Dummerweise habe ich dabei den falschen Link erwischt und nicht das Posting, sondern gleich den ganzen Thread gelöscht. Murphy sei Dank natürlich nicht den mit der herausgelösten, relativ unwichtigen Teildiskussion, sondern den Hauptthread mit stattlichen 361 Beiträgen. Verdammt.

Aber wozu hat man schließlich Backups? Leider konnte ich aber das existierende Backup aus der Nacht zuvor nicht direkt einspielen, denn dann wären ja alle Postings des darauffolgenden Tages futsch gewesen. Also erstmal den Backup-Dump in eine temporäre Datenbank eingelesen um dort die gewünschten 361 Postings zu extrahieren. (Nebenbemerkung: DELETE FROM … WHERE feld <> Nummer geht bei 170.000 Datensätzen quälend langsam. Die gewünschten Daten mit INSERT INTO (SELECT FROM …) in eine temporäre Tabelle zu ziehen, die eigentliche Tabelle zu DROPen, neu anzulegen und die Datensätze wieder zurück zu kopieren geht inklusive der dazugehörigen Tipparbeit deutlich schneller…)

Nachdem das erledigt war, habe ich von der derart auf zwei Tabellen (je eine für Threads und Postings) und wenige Datensätze reduzierten Hilfsdatenbank wiederum einen Dump gemacht, den ich „noch schnell“ in die Produktivdatenbank einfügen wollte. Dabei habe ich aber übersehen, daß MySQL-Standarddumps nicht nur INSERT-Anweisungen, sondern auch CREATE TABLEs und – noch schlimmer – vorgeschaltete DROP TABLEs enthalten. Mit anderen Worten: Nach dem Einspielen des Hilfsdumps hatte ich nicht die alten Daten plus die eigentlich zurückzusichernden Daten, wie ich es eigentlich wollte, sondern nur noch die 361 zurückzuspielenden Postings und einen Thread, der ganze Rest war weg.

Also blieb mir nichts anderes mehr übrig, als zähneknirschen doch das Backup von letzter Nacht direkt einzuspielen und die Postings des Tages für verloren zu erklären. 🙁

Eine gute Seite hatte die Aktion dann aber doch noch: Zum ersten Mal war ich ernsthaft froh, den täglichen Backup-Cronjob eingerichtet und damit überhaupt ein aktuelles Backup zu haben. 😉

Schreibe einen Kommentar