PythonQ 240-8XX Manual de usuario descargar pdf (Pagina 656)

100

101

Anhang A: Probleme und h¨auﬁge Fehler 635

A.4.1 Was zu tun ist, wenn MySQL andauernd abst¨urzt

Alle MySQL-Versionen werden auf vielen Plattformen getestet, bevor sie herausgegeben

werden. Das heißt nicht, dass es keinerlei Bugs in MySQL gibt, aber es heißt, dass, wenn es

Bugs gibt, diese sehr wenige und schwer zu ﬁnden sind. Wenn Sie ein Problem haben, ist

es immer hilfreich herauszuﬁnden, was Ihr System zum Absturz bringt, weil Sie dann viel

bessere Chancen haben, es schnell zu beheben.

Zun¨achst sollten Sie versuchen herauszuﬁnden, ob das Problem darin besteht, dass Ihr

mysqld-Daemon stirbt, oder ob Sie ein Problem mit Ihrem Client haben. Sie k¨onnen her-

ausﬁnden, seit wann Ihr mysqld-Server hochgefahren ist, indem Sie mysqladmin version

ausf¨uhren. Wenn mysqld gestorben ist, ﬁnden Sie den Grund hierf¨ur wom¨oglich in der Datei

‘mysql-daten-verzeichnis/‘hostname‘.err’. Siehe Abschnitt 5.9.1 [Error log], Seite 301.

Viele Abst¨urze von MySQL werden durch besch¨adigte Index- oder Daten-Dateien verur-

sacht. MySQL aktualisiert die Daten auf Platte mit dem write() Systemaufruf, nach

jedem SQL-Statement und bevor der Client ¨uber das Ergebnis unterrichtet wird. (Das

gilt nicht, wenn Sie mit delayed_key_writes fahren, denn in diesem Fall werden nur die

Daten geschrieb en.) Das bedeutet, dass die Daten sicher sind, selbst wenn mysqld abst¨urzt,

weil das Betriebssystem sicherstellt, dass die nicht von MySQL zur¨uckgeschriebenen Daten

(ﬂush) auf Platte zur¨uckgeschrieben werden. Sie k¨onnen MySQL zwingen, alles nach jedem

SQL-Befehl auf Platte zur¨uckzusynchronisieren, indem Sie mysqld mit --flush starten.

Das Gesagte bedeutet, dass Sie normalerweise keine besch¨adigten Tabellen erhalten sollten,

ausser in folgenden F¨allen:

• Jemand oder etwas killte mysqld oder die Maschine mitten w¨ahrend einer Aktual-

isierung.

• Sie haben einen Bug in mysqld gefunden, der dazu f¨uhrte, dass er mitten w¨ahrend einer

Aktualisierung starb.

• Jemand manipuliert die Daten- / Index-Dateien ausserhalb von mysqld, ohne die

Tabelle korrekt zu sperren.

• Wenn Sie viele mysqld-Server auf denselben Daten auf einem System laufen lassen,

das Dateisystem-Sperren nicht gut unterst¨utzt (das wird normalerweise vom lockd-

Daemon gehandhabt) oder wenn Sie mehrere Server mit --skip-locking fahren.

• Wenn Sie eine besch¨adigte Index- / Daten-Datei haben, die sehr falsche Daten enth¨alt,

die mysqld durcheinander brachten.

• Sie haben einen Bug im Datenspeicher-Code gefunden. Das ist nicht sehr wahrschein-

lich, aber zumindest m¨oglich. In diesem Fall k¨onnen Sie versuchen, den Dateityp auf

einen anderen Datenbank-Handler umzustellen, indem Sie ALTER TABLE auf eine repari-

erte Kopie der Tabelle anwenden!

Weil es sehr schwierig ist herauszuﬁnden, warum etwas abst¨urzt, versuchen Sie zuerst her-

auszuﬁnden, ob Dinge, die bei anderen funktionieren, bei Ihnen abst¨urzen, oder ob das

nicht der Fall ist. Versuchen Sie bitte folgendes:

• Fahren Sie den mysqld-Daemon mit mysqladmin shutdown herunter und f¨uhren Sie

myisamchk --silent --force */*.MYI auf alle Tabellen aus. Starten Sie den mysqld-

Daemon erneut. Das stellt sicher, dass Sie von einem sauberen Ausgangszustand aus

fahren. Siehe Kapitel 5 [MySQL Database Administration], Seite 170.

1 2 ... 651 652 653 654 655 656 657 658 659 660 661 ... 767 768

Comentarios a estos manuales

Sin comentarios

PythonQ 240-8XX Manual de usuario Pagina 656

Comentarios a estos manuales

Relacionado con productos y manuales para Sistema De Soldadura PythonQ 240-8XX