Kapitel 2: Vorb emerkungen zum deutschen Handbuch 41
banken auf Inkonsistenzen pr¨ufen und automatisch reparieren oder Warnmeldungen aus-
geben, wenn so etwas passiert. Beachten Sie auch, dass allein durch die Benutzung der
MySQL-Logdatei oder durch das Hinzuf¨ugen einer speziellen Logdatei Tabellen perfekt
repariert werden k¨onnen, ohne dass ein Verlust an Datenintegrit¨at eintritt.
Dar¨uber hinaus k¨onnen fatale transaktionale Updates so umgeschrieben werden, dass sie
atomisch sind. In der Tat gehen wir so weit zu sagen, dass alle Integrit¨atsprobleme,
die Transaktionen l¨osen, mit LOCK TABLES oder atomischen Update durchgef ¨uhrt werden
k¨onnen, was sicherstellt, dass Sie nie einen automatischen Abbruch von der Datenbank
bekommen, was ein gew¨ohnliches Problem transaktionaler Datenbanken darstellt.
Nicht einmal Transaktionen k¨onnen jeden Verlust verhindern, wenn der Server abst¨urzt. In
solchen F¨allen k¨onnen sogar transaktionale Systeme Daten verlieren. Der Unterschied zwis-
chen unterschiedlichen Systemen besteht einzig darin, wie kurz die Zeitverz¨ogerung ist, in
der Daten verloren gehen k¨onnten. Kein System ist 100%-ig sicher, sondern lediglich “sicher
genug”. Selbst von Oracle, ansonsten als das sicherste aller transaktionalen Datenbanken
ber¨uhmt, wird berichtet, dass es manchmal in solchen Situationen Daten verliert.
Um mit MySQL auf der sicheren Seite zu sein, brauchen Sie lediglich Datensicherungen
und angeschaltetes Update-Logging. Damit k¨onnen Sie in jeder denkbaren Situation genau
wie mit jeder beliebigen transaktionalen Datenbank Daten wiederherstellen. Nat¨urlich ist
es immer eine gute Idee, Datensicherungen zu haben, unabh¨angig von der verwendeten
Datenbank.
Das transaktionale Paradigma hat seine Vor- und Nachteile. Viele Benutzer und Applika-
tionsentwickler verlassen sich auf die Einfachheit, mit der sie um Probleme herum Code
schreiben k¨onnen, dort wo anscheinend ein Abbruch erfolgt ist, oder wo es notwendig ist,
haben sie wom¨oglich ein bisschen mehr Arbeit mit MySQL, weil sie anders denken oder
mehr schreiben m¨ussen. Wenn Ihnen atomische Operationen neu sind oder Sie vertrauter
mit Transaktionen sind (oder Sie sich damit besser f¨uhlen), kommen Sie nicht gleich zur
Schlussfolgerung, dass sich MySQL nicht mit diesen
¨
Uberlegungen besch¨aftigt hat. Zu-
verl¨assigkeit und Integrit¨at stehen f¨ur uns absolut im Vordergrund. Aktuelle Sch¨atzungen
gehen davon aus, dass zur Zeit mehr als eine Million mysqld-Server laufen, von denen viele
in Produktionsumgebungen eingesetzt werden. Wir h¨oren sehr, sehr selten von Benutzern,
die irgendwelche Daten verloren haben, und in fast allen F¨allen sind Benutzerfehler im Spiel.
Das ist unserer Meinung nach der beste Beweis f¨ur die Stabilit¨at und Zuverl¨assigkeit von
MySQL.
Im ¨ubrigen lassen die aktuellen Features von MySQL Zuverl¨assigkeit und Integrit¨at auf
Transaktionsebene oder besser zu, wenn in bestimmten Situationen Integrit¨at von h¨ochster
Wichtigkeit ist. Wenn Sie Tabellen mit LOCK TABLES sperren, werden alle Updates ange-
halten, bis jegliche Integrit¨atspr¨ufungen durchgef¨uhrt sind. Wenn Sie nur eine Lesesperre
(Read Lock) machen (im Gegensatz zu einer Schreibsperre - Write Lock), werden Lese-
und Einf¨ugeoperationen noch zugelassen. Die neu eingef¨ugten Datens¨atze k¨onnen von nicht
Clients gesehen werden, die eine READ-Sperre haben, bis sie ihre Lesesperre aufheben. Mit
INSERT DELAYED k¨onnen Sie Einf¨ugeoperationen in eine lokale Warteschlange (Local Queue)
stellen, solange, bis die Sperren aufgehoben sind, ohne dass der Client warten muss, bis
die Einf¨ugeoperationen a/jointfilesconvert/293675/bgeschlossen sind. Siehe Abschnitt 7.4.4 [INSERT DELAYED],
Seite 443.
“Atomisch”, so wie wir es meinen, ist nichts Magisches. Es b edeutet nur, dass Sie sicher sein
k¨onnen, dass kein anderer Benutzer mit irgendeinem laufenden Update in Konflikt kommen
Comentarios a estos manuales