Letztens in einem IRC Channel:
10:52 < ads> und die Anzahl Optionen, die es da zum Reparieren gibt, lassen entfernt ahnen, wie gruselig die Details sein müssen
10:52 < mlelstv> ads, es gibt nur 2
10:52 < ads> Jor: richtige DBs haben Transaktionen und ACID und Logs und so
10:52 < ads> mlelstv: was, 2
10:52 < mlelstv> optionen zum reparieren :)
10:53 < ads> --correct-checksum (Hallo?)
10:53 < ads> --data-file-length (Hallo, will ich eigentlich alle Daten wiederhaben oder reichts mir, wenn 20% noch da sind?)
10:53 <@Jor> ich finde das halt Traurig, welche Qualitaet mysql an den Tag legt. Ich hab Oracle-DBs schon vor 10 Jahren explodieren sehen, wo die Raids auf denen die Dat
enfiles und rollbacks lagen sich zerlegten... nach dem zusammenflicken derselben und einigem automatischen reparrieren beim naechsten oraclestart war die DB dann (minus
der zerstoerten letzten Transaktionen) aber wieder da. Ohne weiteren Datenverlust
10:54 < ads> --extend-check (reparieren wir halt etwas mehr ...)
10:54 < ads> --recover (Ach, da gibts noch paar Sachen, die mal auftreten, die könnten wir auch reparieren)
10:54 < ads> --safe-recover (Machs mit Gummi, Baby)
10:54 < mlelstv> jor, da hat dann auch kein admin an den datenfiles gepfuscht, und sei es weil oracle nur auf rohe platten geschrieben hat.
10:55 < ads> --quick (reparier halt nicht alles, nur die Hälfte)
10:55 <@double-p> rotfl
10:55 <@double-p> ads: heor auf, ich kann nimmer
10:55 < ads> double-p: da gibts noch mehr ...
Categories:
[Other-Dbs]