5
Probleme mit mysql installation
Hallo Zusammen
Habe eine neue Debian etch 4.0 installation. Ich wollte nun das packet mysql-server installieren:
apt-get install mysql-server
Die installation hat jedoch nicht geklappt und nun habe ich bei jedem apt-get upgrade o.ä. eine error meldung:
Richte mysql-server-5.0 ein (5.0.32-7etch6) ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.0 (--configure):
Unterprozess post-installation script gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
mysql-server-5.0
E: Sub-process /usr/bin/dpkg returned an error code (1)
Mein syslog meint dazu folgendes:
Aug 4 22:10:55 alpha mysqld_safe[19570]: started
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Database was not shut down normally!
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Starting crash recovery.
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Reading tablespace information from the .ibd files...
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Restoring possible half-written data pages from the doublewrite
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: buffer...
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Starting log scan based on checkpoint at
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: log sequence number 0 8204.
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Doing recovery: scanned up to log sequence number 0 8204
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page directory corruption: supremum not pointed to
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page dump in ascii and hex (16384 bytes):
Aug 4 22:10:56 alpha mysqld[19573]: len 16384; hex blablabla
Aug 4 22:10:56 alpha mysqld[19573]: ;InnoDB: End of page dump
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page checksum 1575996416, prior-to-4.0.14-form checksum 1371122432
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page lsn 0 0, low 4 bytes of lsn at page end 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page number (if stored to page already) 0,
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page directory corruption: supremum not pointed to
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page dump in ascii and hex (16384 bytes):
Aug 4 22:10:56 alpha mysqld[19573]: len 16384; hex
blablablabla
Aug 4 22:10:57 alpha mysqld[19573]: ;InnoDB: End of page dump
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57 InnoDB: Page checksum 1575996416, prior-to-4.0.14-form checksum 1371122432
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Page lsn 0 0, low 4 bytes of lsn at page end 0
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Page number (if stored to page already) 0,
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57InnoDB: Error: trying to access a stray pointer 0x3635fff8
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: buf pool start is at 0xb6350000, end at 0xb6b50000
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Probable reason is database corruption or memory
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: corruption. If this happens in an InnoDB database recovery, see
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: how to force recovery.
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57InnoDB: Assertion failure in thread 3083971232 in file ./../include/buf0buf.ic line 259
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: We intentionally generate a memory trap.
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: If you get repeated assertion failures or crashes, even
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: immediately after the mysqld startup, there may be
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: about forcing recovery.
Aug 4 22:10:57 alpha mysqld[19573]: mysqld got signal 11;
Aug 4 22:10:57 alpha mysqld[19573]: This could be because you hit a bug. It is also possible that this binary
Aug 4 22:10:57 alpha mysqld[19573]: or one of the libraries it was linked against is corrupt, improperly built,
Aug 4 22:10:57 alpha mysqld[19573]: or misconfigured. This error can also be caused by malfunctioning hardware.
Aug 4 22:10:57 alpha mysqld[19573]: We will try our best to scrape up some info that will hopefully help diagnose
Aug 4 22:10:57 alpha mysqld[19573]: the problem, but since we have already crashed, something is definitely wrong
Aug 4 22:10:57 alpha mysqld[19573]: and this may fail.
Aug 4 22:10:57 alpha mysqld[19573]:
Aug 4 22:10:57 alpha mysqld[19573]: key_buffer_size=0
Aug 4 22:10:57 alpha mysqld[19573]: read_buffer_size=131072
Aug 4 22:10:57 alpha mysqld[19573]: max_used_connections=0
Aug 4 22:10:57 alpha mysqld[19573]: max_connections=100
Aug 4 22:10:57 alpha mysqld[19573]: threads_connected=0
Aug 4 22:10:57 alpha mysqld[19573]: It is possible that mysqld could use up to
Aug 4 22:10:57 alpha mysqld[19573]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K
Aug 4 22:10:57 alpha mysqld[19573]: bytes of memory
Aug 4 22:10:57 alpha mysqld[19573]: Hope that's ok; if not, decrease some variables in the equation.
Aug 4 22:10:57 alpha mysqld[19573]:
Aug 4 22:10:57 alpha mysqld[19573]: thd=(nil)
Aug 4 22:10:57 alpha mysqld[19573]: Attempting backtrace. You can use the following information to find out
Aug 4 22:10:57 alpha mysqld[19573]: where mysqld died. If you see no messages after this, something went
Aug 4 22:10:57 alpha mysqld[19573]: terribly wrong...
Aug 4 22:10:57 alpha mysqld[19573]: Cannot determine thread, fp=0xbfff917c, backtrace may not be correct.
Aug 4 22:10:57 alpha mysqld[19573]: Stack range sanity check OK, backtrace follows:
blablablabla
Aug 4 22:10:57 alpha mysqld[19573]: New value of fp=(nil) failed sanity check, terminating stack trace!
Aug 4 22:10:57 alpha mysqld[19573]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Aug 4 22:10:57 alpha mysqld[19573]: stack trace is much more helpful in diagnosing the problem, so please do
Aug 4 22:10:57 alpha mysqld[19573]: resolve it
Aug 4 22:10:57 alpha mysqld[19573]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Aug 4 22:10:57 alpha mysqld[19573]: information that should help you find out what is causing the crash.
Aug 4 22:10:57 alpha mysqld_safe[19597]: ended
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Wie kriege ich das ding wieder los?
Habe eine neue Debian etch 4.0 installation. Ich wollte nun das packet mysql-server installieren:
apt-get install mysql-server
Die installation hat jedoch nicht geklappt und nun habe ich bei jedem apt-get upgrade o.ä. eine error meldung:
Richte mysql-server-5.0 ein (5.0.32-7etch6) ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.0 (--configure):
Unterprozess post-installation script gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
mysql-server-5.0
E: Sub-process /usr/bin/dpkg returned an error code (1)
Mein syslog meint dazu folgendes:
Aug 4 22:10:55 alpha mysqld_safe[19570]: started
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Database was not shut down normally!
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Starting crash recovery.
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Reading tablespace information from the .ibd files...
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Restoring possible half-written data pages from the doublewrite
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: buffer...
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Starting log scan based on checkpoint at
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: log sequence number 0 8204.
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Doing recovery: scanned up to log sequence number 0 8204
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page directory corruption: supremum not pointed to
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page dump in ascii and hex (16384 bytes):
Aug 4 22:10:56 alpha mysqld[19573]: len 16384; hex blablabla
Aug 4 22:10:56 alpha mysqld[19573]: ;InnoDB: End of page dump
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page checksum 1575996416, prior-to-4.0.14-form checksum 1371122432
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page lsn 0 0, low 4 bytes of lsn at page end 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page number (if stored to page already) 0,
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Aug 4 22:10:56 alpha mysqld[19573]: InnoDB: Page directory corruption: supremum not pointed to
Aug 4 22:10:56 alpha mysqld[19573]: 080804 22:10:56 InnoDB: Page dump in ascii and hex (16384 bytes):
Aug 4 22:10:56 alpha mysqld[19573]: len 16384; hex
blablablabla
Aug 4 22:10:57 alpha mysqld[19573]: ;InnoDB: End of page dump
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57 InnoDB: Page checksum 1575996416, prior-to-4.0.14-form checksum 1371122432
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Page lsn 0 0, low 4 bytes of lsn at page end 0
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Page number (if stored to page already) 0,
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57InnoDB: Error: trying to access a stray pointer 0x3635fff8
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: buf pool start is at 0xb6350000, end at 0xb6b50000
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Probable reason is database corruption or memory
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: corruption. If this happens in an InnoDB database recovery, see
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: how to force recovery.
Aug 4 22:10:57 alpha mysqld[19573]: 080804 22:10:57InnoDB: Assertion failure in thread 3083971232 in file ./../include/buf0buf.ic line 259
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: We intentionally generate a memory trap.
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: If you get repeated assertion failures or crashes, even
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: immediately after the mysqld startup, there may be
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Aug 4 22:10:57 alpha mysqld[19573]: InnoDB: about forcing recovery.
Aug 4 22:10:57 alpha mysqld[19573]: mysqld got signal 11;
Aug 4 22:10:57 alpha mysqld[19573]: This could be because you hit a bug. It is also possible that this binary
Aug 4 22:10:57 alpha mysqld[19573]: or one of the libraries it was linked against is corrupt, improperly built,
Aug 4 22:10:57 alpha mysqld[19573]: or misconfigured. This error can also be caused by malfunctioning hardware.
Aug 4 22:10:57 alpha mysqld[19573]: We will try our best to scrape up some info that will hopefully help diagnose
Aug 4 22:10:57 alpha mysqld[19573]: the problem, but since we have already crashed, something is definitely wrong
Aug 4 22:10:57 alpha mysqld[19573]: and this may fail.
Aug 4 22:10:57 alpha mysqld[19573]:
Aug 4 22:10:57 alpha mysqld[19573]: key_buffer_size=0
Aug 4 22:10:57 alpha mysqld[19573]: read_buffer_size=131072
Aug 4 22:10:57 alpha mysqld[19573]: max_used_connections=0
Aug 4 22:10:57 alpha mysqld[19573]: max_connections=100
Aug 4 22:10:57 alpha mysqld[19573]: threads_connected=0
Aug 4 22:10:57 alpha mysqld[19573]: It is possible that mysqld could use up to
Aug 4 22:10:57 alpha mysqld[19573]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K
Aug 4 22:10:57 alpha mysqld[19573]: bytes of memory
Aug 4 22:10:57 alpha mysqld[19573]: Hope that's ok; if not, decrease some variables in the equation.
Aug 4 22:10:57 alpha mysqld[19573]:
Aug 4 22:10:57 alpha mysqld[19573]: thd=(nil)
Aug 4 22:10:57 alpha mysqld[19573]: Attempting backtrace. You can use the following information to find out
Aug 4 22:10:57 alpha mysqld[19573]: where mysqld died. If you see no messages after this, something went
Aug 4 22:10:57 alpha mysqld[19573]: terribly wrong...
Aug 4 22:10:57 alpha mysqld[19573]: Cannot determine thread, fp=0xbfff917c, backtrace may not be correct.
Aug 4 22:10:57 alpha mysqld[19573]: Stack range sanity check OK, backtrace follows:
blablablabla
Aug 4 22:10:57 alpha mysqld[19573]: New value of fp=(nil) failed sanity check, terminating stack trace!
Aug 4 22:10:57 alpha mysqld[19573]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Aug 4 22:10:57 alpha mysqld[19573]: stack trace is much more helpful in diagnosing the problem, so please do
Aug 4 22:10:57 alpha mysqld[19573]: resolve it
Aug 4 22:10:57 alpha mysqld[19573]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Aug 4 22:10:57 alpha mysqld[19573]: information that should help you find out what is causing the crash.
Aug 4 22:10:57 alpha mysqld_safe[19597]: ended
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Aug 4 22:11:10 alpha /etc/init.d/mysql[28658]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Wie kriege ich das ding wieder los?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 93599
Url: https://administrator.de/contentid/93599
Printed on: April 20, 2024 at 00:04 o'clock
5 Comments
Latest comment
Hi samsx87,
falls Du noch keine Datenbank installiert hast (was ja nicht so klingt) versuche mal einen 'aptitude purge mysql-server-5.0" und anschließend einen 'aptitude clean'.
Hast Du Deine sources.lst verändert?
Gruß,
Martin
falls Du noch keine Datenbank installiert hast (was ja nicht so klingt) versuche mal einen 'aptitude purge mysql-server-5.0" und anschließend einen 'aptitude clean'.
Hast Du Deine sources.lst verändert?
Gruß,
Martin
Hi,
schau aus, als wenn die DB mit Mysql 4 nicht sauber geschlossen wurde, dann der 5er Server draufkam und der den Fehler nicht reparieren konnte. Spiel doch mal die Datensicherung ein, starte den 4er Server noch mal und lass den die DB reparieren und fahre dann den Server runter und aktualisiere dann auf 5 und dann noch mal versuchen - Du hast doch eine Datensicherung, oder????
Spass beiseite, Backup ziehen, 5er Server deinistallieren, 4er Server installieren und schauen, ob das geht, dann 4er Server sauber runterfahren, dann deinstallieren, 5er Server installieren und schauen, was geht.
Nicht empfehlen würde ich Pakete aus dem Testing oder Developmentzweig - das bringt wohl wenig was, wenn Dir dadurch das System um die Ohren fliegt ...
Grüße
schau aus, als wenn die DB mit Mysql 4 nicht sauber geschlossen wurde, dann der 5er Server draufkam und der den Fehler nicht reparieren konnte. Spiel doch mal die Datensicherung ein, starte den 4er Server noch mal und lass den die DB reparieren und fahre dann den Server runter und aktualisiere dann auf 5 und dann noch mal versuchen - Du hast doch eine Datensicherung, oder????
Spass beiseite, Backup ziehen, 5er Server deinistallieren, 4er Server installieren und schauen, ob das geht, dann 4er Server sauber runterfahren, dann deinstallieren, 5er Server installieren und schauen, was geht.
Nicht empfehlen würde ich Pakete aus dem Testing oder Developmentzweig - das bringt wohl wenig was, wenn Dir dadurch das System um die Ohren fliegt ...
Grüße
Hallo Zusammen
aptitude purge mysql-server-5.0 <- hat funktioniert, Danke!
Nach einer neu installation ist das Problem jedoch wieder das selbe (es ist ein neues System ohne Datenbanken). Ist 100MB RAM zu wenig für mysql?
aptitude purge mysql-server-5.0 <- hat funktioniert, Danke!
Nach einer neu installation ist das Problem jedoch wieder das selbe (es ist ein neues System ohne Datenbanken). Ist 100MB RAM zu wenig für mysql?
Hi,
100 MB ist nicht die Welt, reicht aber.
Frage - der Ram ist in Ordnung, ja? Es gab bisher keine unkontrollierten Abstürze? Was passiert, wenn Du im Bios das RAM-Timing etwas konservativer einstellst?
Grüße Mathias
100 MB ist nicht die Welt, reicht aber.
Frage - der Ram ist in Ordnung, ja? Es gab bisher keine unkontrollierten Abstürze? Was passiert, wenn Du im Bios das RAM-Timing etwas konservativer einstellst?
Grüße Mathias
Hallo Nailara
Nein, der server ist neu (v-server) also neu aufgesetzt. es war also nie eine DB darauf vorhanden. Ins BIOS habe ich keinen Zugriff... Nützt es was, wenn ich das pagefile herauf schraube (wie?)
Gruss
Nein, der server ist neu (v-server) also neu aufgesetzt. es war also nie eine DB darauf vorhanden. Ins BIOS habe ich keinen Zugriff... Nützt es was, wenn ich das pagefile herauf schraube (wie?)
Gruss
