Mal wieder MySQL-Probleme

S

s24!

Registered User
Guten Abend,

MySQL mag mich nicht. Anders kann ich es mir nicht erklären, dass ich dauernd Probleme damit habe. :P

Folgendes ist passiert: Irgendwann im Laufe des Tages ist der MySQL abgeschmiert, aber so richtig - da half nur noch stop & start. Brachte aber auch nur bedingt was, denn jetzt schmierte er wieder alle paar Minuten ab (startete sich aber umgehend neu). Das hatten wir schonmal, es löste sich dann in Luft auf irgendwie. Scheinbar von alleine. ;)
Jedenfalls erzählte InnoDB im Log, dass ein reboot das Problem lösen konnte. Ich hatte langsam keinen Nerv mehr und habe die Maschine neugestartet - tada, Probleme weg. Theoretisch. Das Ding läuft ohne Abstürze, kriegt auch seine durchschnittlichen 1000 Queries und mehr pro Sekunde hin. Aber ich würde nach dem Crash natürlich gerne mal wieder die Datenbanken durchchecken lassen und ein vollständiges Backup anlegen.

Es mag an der Uhrzeit liegen, aber ich kriege es nicht mehr auf die Reihe, alle Datenbanken durchzuprüfen. Manche Tabellen unterstützen kann ANALYZE, andere kein CHECK und ganz viele (so mein Eindruck) mögen REPAIR auch nicht. Ich suche hier also nach einer Methode, alle möglichen Tabellen & Datenbanken auf dem Server zu überprüfen und zu reparieren, falls notwendig. Egal, von welchem Typ diese sind. :/ - Darf auch gerne etwas länger dauern.
Natürlich habe ich schon etwas mit mysqlcheck gearbeitet, aber das liefert mir lustige Anweisungen. Ich soll z.B. Tabellen reparieren, die REPAIR überhaupt nicht unterstützen. :confused: Wie gesagt: Ich blicke nicht mehr ganz durch und wäre über Hilfe dankbar.
mysqlcheck bricht übrigens auch gelegentlich ab, weil:
Code: 
mysqlcheck: Got error: 1102: Incorrect database name '' when executing 'REPAIR TABLE ... '
Es gibt aber keine Datenbank, die keinen Namen hat. :rolleyes:
Das konnte ich wenigstens mit --force überbrücken.

Ansonsten finde ich solche Sachen im Log:
Code: 
110907  2:27:20 [Warning] Aborted connection 8 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:27:20 [Warning] Aborted connection 9 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:27:20 [Warning] Aborted connection 5 to db: 'unconnected' user: 'debian-sys-maint' host: 'localhost' (Got timeout reading communication packets)
110907  2:27:48 [Warning] Aborted connection 15 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:28:15 [Warning] Aborted connection 8601 to db: 'webuserxyz' user: 'webuserxyz' host: 'localhost' (Got an error reading communication packets)
110907  2:28:44 [Warning] Aborted connection 8357 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:28:44 [Warning] Aborted connection 8359 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:28:44 [Warning] Aborted connection 8349 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:28:47 [Warning] Aborted connection 9267 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:30:29 [Warning] Aborted connection 36830 to db: 'information_schema' user: 'debian-sys-maint' host: 'localhost' (Got an error writing communication packets)
110907  2:30:29 [Warning] Aborted connection 36818 to db: 'information_schema' user: 'debian-sys-maint' host: 'localhost' (Got an error writing communication packets)
110907  2:30:32 [Warning] Aborted connection 35163 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:30:32 [Warning] Aborted connection 35164 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:30:32 [Warning] Aborted connection 35158 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:31:56 [Warning] Aborted connection 51426 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
110907  2:32:36 [Warning] Aborted connection 51430 to db: 'syscp' user: 'syscp' host: 'localhost' (Got timeout reading communication packets)
Kann man das getrost ignorieren? Meines Wissens nach gab's das schon vorher dauernd...

Jetzt zum versuchten Backup...
Code: 
mysqldump --all-databases --opt > all_databases.sql
Das lasse ich eine Weile laufen, dann stürzt mir der MySQL-Server wieder ab. Kann es sein, dass der ein Problem mit über 1000 Datenbanken hat?
Seit den Abstürzen die ich mit dem mysqldump erzeugt habe gibt's auch wieder regelmäßige Abstürze. Im Log steht folgendes:

Code: 
< Hier steht der Pagedump >
;InnoDB: End of page dump
110907  2:50:15  InnoDB: Page checksum 1045966193, prior-to-4.0.14-form checksum 562696334
InnoDB: stored checksum 4089116977, prior-to-4.0.14-form stored checksum 562696334
InnoDB: Page lsn 0 2836276424, low 4 bytes of lsn at page end 2836276424
InnoDB: Page number (if stored to page already) 18871,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 159690
InnoDB: (index "PRIMARY" of table "webuserxyz"."locales_target")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 18871.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
110907 02:50:18 mysqld_safe Number of processes running now: 0
110907 02:50:18 mysqld_safe mysqld restarted
110907  2:50:18 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
110907  2:50:18 [Note] Plugin 'FEDERATED' is disabled.
110907  2:50:18  InnoDB: Initializing buffer pool, size = 8.0M
110907  2:50:18  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 1 75143630
110907  2:50:18  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1 75154415
110907  2:50:19  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
110907  2:50:19  InnoDB: Started; log sequence number 1 75154415
110907  2:50:20 [Note] Event Scheduler: Loaded 0 events
110907  2:50:20 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.57-1~dotdeb.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)

Vermutlich löst ein Reboot das Problem jetzt wieder - aber das kann ja keine Lösung sein.
Wenigstens erzählt mir MySQL seit meinen mysqlcheck-Spielereien nichts mehr von gecrashten Tabellen. =)


Vielen Dank für eure Hilfe und entschuldigt bitte den Roman! :)


Nachtrag: Jetzt läuft MySQL - ohne reboot oder sonstwas - seit zwanzig Minuten wieder stabil. Ich werd nicht schlau draus. Wenn sich das jemand persönlich ansehen will (und kann!), bitte PN schreiben.

Nachtrag 2: Direkt nach dem Edit gerade ist das Ding wieder abgestürzt. Im Log wieder das gleiche wie oben. Mir fällt dabei auf: Der Server redet konkret von der Tabelle "locales_target" aus der Datenbank "webuserxyz" UND im Pagedump steht immer das gleiche...


Gute Nacht. ;)
 
Last edited by a moderator:
InnoDB kennt den REPAIR TABLE Befehl nicht. Aber deine Fehlermeldung weiter oben liefert dir doch sogar den Link, um eine defekt InnoDB-Tabelle wieder herzustellen. Die betroffene Tabelle scheinst du ja zu kennen - aber es schadet ja nicht, sie noch einmal mit einem CHECK TABLE zu prüfen.
 
Hey Leute,

ich hatte das schon alles fast wieder vergessen, denn bis gerade lief MySQL ohne ein einziges Problemchen die fünf Tage durch. Dann wieder der selbe Mist, mit ner anderen DB allerdings.
Im mysqld.err steht natürlich wieder ein netter Link (forcing InnoDB recovery), also sorgt jetzt ein
Code: 
innodb_force_recovery = 1
schonmal dafür, dass die kaputten Tabellen den Server nicht crashen lassen.

Leider wird mir nicht ganz klar, wie ich die betroffenen Tabellen jetzt reparieren kann. :confused:

Code: 
root@server3:~# mysqlcheck webusersql1 --check
webusersql1.table
error    : Table upgrade required. Please do "REPAIR TABLE `table`" or dump/reload to fix it!

Wenig überraschend:
Code: 
root@server3:~# mysqlcheck webusersql1 --repair
webusersql1.table
note     : The storage engine for the table doesn't support repair

Ich steig da nicht durch. MyISAM kann ich mittlerweile reparieren, aber bei InnoDB bin ich trotz Google ratlos...


Vielen Dank für die nette Hilfe hier! :)
 
*Seufz* Und das passiert wenn jemand sich nicht erinnert dass ich die genauen Instruktionen wie man sowas "heile macht" ihm geschickt hab, gelle s24! ;)

  • zuerst die error-log aktivieren falls nicht aktiv
  • dann dort die kaputte(n) Tabelle(n) auslesen
  • inodb dann mit innodb_force_recovery = (1 bis 3 wobei 3 das agressivste ist) in einen read-only modus setzen
  • MySQL neu starten
  • mysqldump auf die Datenbank
  • innodb_force_recovery wieder auf 0
  • MySQL neu starten
  • und mysqldump einspielen
  • fixed =)
 
Psst. :D

So haben wir es dann auch hingekriegt, nur leider kam dann heute wieder ein Crash einiger Tabellen, die MySQL laut Log dann aber selbst reparieren konnte.
Mir ist einfach nicht klar, warum dauernd irgendwas "kaputtgeht". Normalerweise sollte sowas doch wenn überhaupt bei einem "Abschießen" von MySQL passieren. Es passiert aber scheinbar grundlos, und ein Muster erkenne ich nicht.

d4f meinte, es könnte Probleme mit dem Dateisystem geben - was meint ihr?
Ist ein ext3 in einem Soft-RAID-1, falls das hilft...


Grüße
 
Danke für deine Antwort!
Nach Lesen der Manpage gehe ich davon aus, dass das mit -nf auch erstmal nur prüft und demnach nichts kaputtmachen kann. Werde das morgen mal durchführen.

Gute Nacht :)
 
You must log in or register to reply here.
Back
Top