Datenbankfehler nach Abturtz

W

webcreation

New Member
Hallo Community,


nach dem Login als Admin erhalte ich folgende Fehlermeldung:

MySQL query failed: MySQL server has gone away

0: /usr/local/psa/admin/plib/common_func.php3:250
db_query(string 'SELECT cb.id FROM custom_buttons cb WHERE cb.place = "admin" AND (cb.level >= "1" OR (cb.level < "1" AND cb.options & "128")) AND cb.level ="1" GROUP BY cb.id ORDER BY cb.level ASC, cb.sort_key ASC, cb.text ASC')
1: /usr/local/psa/admin/plib/class.CustomButtonManager.php:78
CustomButtonManager::getButtons(integer '1', integer '1', integer '0', string 'admin')
2: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:1292
DashboardElement_custom_buttons->renderHtml(object of type UserAdmin, NULL null)
3: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:606
DashboardElement->renderHtml_buttons(array, object of type UserAdmin, NULL null)
4: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:551
DashboardElement->renderHtml_common(array, object of type UserAdmin, NULL null)
5: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:944
DashboardElement_section->renderHtml(object of type UserAdmin, NULL null)
6: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:557
DashboardElement->renderHtml_common(array, object of type UserAdmin, NULL null)
7: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:564
DashboardElement->renderHtml(object of type UserAdmin, NULL null)
8: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:898
DashboardElement_column->renderHtml(object of type UserAdmin, NULL null)
9: /usr/local/psa/admin/plib/dashboard/DashboardElement.php:571
DashboardElement::renderHtml_columns(array, object of type UserAdmin, NULL null)
10: /usr/local/psa/admin/plib/dashboard/Dashboard.php:197
Dashboard::renderHtml(array, object of type UserAdmin)
11: /usr/local/psa/admin/plib/dashboard/DashboardForm.php:95
DashboardForm->assign(array, object of type UserAdmin)
12: /usr/local/psa/admin/plib/dashboard/DashboardLocation.php:55
DashboardLocation->accessItem(string 'GET', NULL null)
13: /usr/local/psa/admin/plib/UIPointer.php:519
UIPointer->access(string 'GET')
14: /usr/local/psa/admin/htdocs/plesk.php:19
Click to expand...


Wenn ich mit mysqldump ausführe erhalte ich die Meldung
mysqldump: Got error: 2013: Lost connection to MySQL server during query when using LOCK TABLES
Click to expand...

Allerdings connecten mit der Datenbank funktioniert. Webprojekte sind davon auch nicht betroffen.


Die log Datei enthält folgende Meldung:
;InnoDB: End of page dump
081111 11:05:45 InnoDB: Page checksum 2700799190, prior-to-4.0.14-form checksum 2694492373
InnoDB: stored checksum 543319393, prior-to-4.0.14-form stored checksum 0
InnoDB: Page lsn 1847609699 1746952809, low 4 bytes of lsn at page end 0
InnoDB: Page number (if stored to page already) 1919051113,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 1684369952
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 263.
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 InnoDB: MySQL :: MySQL 5.0 Reference Manual :: 13.2.7.1 Forcing InnoDB Recovery
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.

Number of processes running now: 0
081111 11:05:45 mysqld restarted
081111 11:05:45 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...
081111 11:05:45 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 502725932.
InnoDB: Doing recovery: scanned up to log sequence number 0 502725942
081111 11:05:45 InnoDB: Started; log sequence number 0 502725942
081111 11:05:45 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
Click to expand...

Hat jemand einen Tipp für mich wie ich weiter vorgehen soll? Bzw. wie kann ich die alte DB sichern und ein Backup einspielen?


Viele Grüße
Tobias
 
Hi,

log dich mal auf die mysql-Console ein und führe folgende Befehle aus:

Code: 
use psa;
analyze table custom_buttons;
repair table custom_buttons;
optimize table custom_buttons;

Eventuell für andere Tabellen noch wiederholen, sofern Folgefehler auftreten sollten.


-W
 
Hallo,

beim Ausführen von analyze der Tabelle psa.mail_resp erhalte ich folgende Fehlermeldung:

Code: 
mysql> analyze table mail_resp;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    5
Current database: psa

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
ERROR: 
Can't connect to the server

Hier noch einmal eine kleine Zusammenfassung was mir bis jetzt aufgefallen ist:
- Beim überprüfen der Datenbank sind mir die Tabellen psa.mail_resp und information_schema.COLLATIONS aufgefallen
- auf beide kann ich nicht mehr auf Konsolen-Ebene zugreifen (mysqldump und mysqlcheck)
- bei mysqlcheck erscheint folgender Fehler: "Got error: 2013: Lost connection to MySQL server during query when executing 'CHECK TABLE ... '"
- das merkwürdige ist wenn ich ein Backup der psa Datenbank in der Datenbank psa2 einspiele funktioniert alles ohne Probleme
- sobald ich die psa Datenbank lösche und das alte Backup in psa einspiele erhalte ich den selben Fehler wie beim mysqlcheck

Hat noch jemand eine Idee für mich? Vielen Dank.

Grüße
Tobias
 
Entweder ist die ImmoDB-Datei kaputt oder die psa/mail_resp.frm.
Aufgrund des Backups und dem wieder einspielen, tippe ich auf die ImmoDB.

Ich würde das Backup als SQL-Dump speichern, die gesamte psa-DB löschen und die ImmoDB-Dateien in /var/lib/mysql/.
Danach das Backup wieder einspielen und hoffen das es geht.

Achtung: Mein Vorschlag geht nur, wenn sonst keine Datenbanken ImmoDB nutzt!

huschi.
 
Hallo Huschi,


danke für deine Hilfe. Was für eine Ehre das der Meister persönlich hilft. ;-)

Leider benutzen ich noch andere Datenbanken mit InnoDB.

Wir schweben jetzt noch zwei Möglichkeiten vor:
- Plesk eine andere Datenbank zuweisen und die DB psa ignorieren
- Oder einen Dump erstellen ohne die betroffenen Tabellen und Mysql komplett neu aufsetzen und den Dump + den fehlenden Teil von einem alten Backup einspielen.

Was ist den das beste Vorgehen für das komplette löschen und neu installiern von MySQL? Und hat jemand Erfahrungen damit ob das Auswirkungen auf Plesk hat?


Viele Grüße
Tobias

PS: Das verrückte ist wenn ich die Tabelle psa.mail_resp manuell entferne, ist die nächste Tabelle betroffen ?¿?¿?
 
webcreation said:
Was für eine Ehre das der Meister persönlich hilft. ;-)
Click to expand...
Ein "Meister" zeichnet sich dadurch aus, daß er seinen Schülern zur Seite steht.
Wer seinen Schülern nicht zur Seite steht, ist auch kein Meister.
(alte Chinesische Nasenweißheit)

Was ist den das beste Vorgehen für das komplette löschen und neu installiern von MySQL?
Click to expand...
Es nicht zu tun. Denn von MySQL hängen zuviele Pakete ab. Und das /var/lib/mysql/-Verzeichnis wird davon meistens gar nicht berührt.
Der Fehler liegt aber nicht im MySQL-Server sondern in den Daten.
Ergo: Keine Lösung.

wenn ich die Tabelle psa.mail_resp manuell entferne, ist die nächste Tabelle betroffen
Click to expand...
Evtl. sind lediglich die InnoDB-Logfiles defekt. Versuch es mal wie folgt:
Code: 
/etc/init.d/mysql stop
cd /var/lib/mysql
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak
/etc/init.d/mysql start
Falls es nicht die Lösung war, kannst Du sie ja einfach wieder herstellen.

huschi.
 
Hallo,


das hat leider nicht geklappt - es hatte kein Auswirkung.

Was mich stutzig macht ist das bei jedem Start die crash recovery startet:
Code: 
Number of processes running now: 0
081113 00:11:54  mysqld restarted
081113  0:11:54  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...
081113  0:11:54  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 619608086.
InnoDB: Doing recovery: scanned up to log sequence number 0 619608086
081113  0:11:54  InnoDB: Started; log sequence number 0 619608086
081113  0:11:54 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.45'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Wo werden denn die Informationen gespeichert das die Datenbank nicht korrekt beendet worden ist?


Viele Grüße
Tobias
 
webcreation said:
Wo werden denn die Informationen gespeichert das die Datenbank nicht korrekt beendet worden ist?
Click to expand...
Im Datenbank-File selbst. Bei InnoDB wird grundsätzlich beim Starten ein Check über die Datenfiles und die Logfiles gestartet. Die Transaktionen müssen Synchronisiert werden.

huschi.
 
Danke für die Hilfe Huschi.


Also am besten dann alle InnoDB Files entfernen und die Logfiles(ib_logfile0,ib_logfile1) ebenfalls. Danach MySQL wieder starten, und hoffen das er dann nicht mehr meckert. Und anschließen die Backups von den InnoDB wieder einspielen. So korrekt?

Das werde ich mal Heute Abend/Nacht probieren.


Tobias
 
webcreation said:
Also am besten dann alle InnoDB Files entfernen
Click to expand...
Nein, das wäre Fatal. Das sprengt die ganze Plesk-Datenbank (da fast alle Tabellen per InnoDB angelegt sind).
Dann funktioniert fast alles nicht mehr.

Man könnte aber versuchen alle InnoDB-Tabellen in MyIsam umzuwandeln.

huschi.
 
Hallo,


das ist der Inhalt, meiner "my.cnf":
Code: 
[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
max_connections=3000
key_buffer=512M
table_cache=1024
sort_buffer=40M
net_read_timeout=60
connect_timeout=10
#innodb_force_recovery = 4


[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Gibt es den eine Möglichkeit das Recovery zu unterdrücken, und das die Fehlerhafte Tabelle gelöscht werden? Ich hab ja eine Sicherung von den Daten. Also praktisch das Gegenteil von "innodb_force_recovery".


Viele Grüße
Tobias
 
You must log in or register to reply here.
Back
Top