Mysql startet plötzlih nicht mehr

Hallo zusammen!

Seit heute startet plötzlich mysql nicht mehr.

hier ein Auszug aus dem syslog:

Sep 14 20:16:58 mail mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql Sep 14 20:16:58 mail mysqld: 160914 20:16:58 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. Sep 14 20:16:58 mail mysqld: 160914 20:16:58 [Note] /usr/sbin/mysqld (mysqld 5.5.46-0.17.201512141630-log) starting as process 7379 ... Sep 14 20:16:58 mail mysqld: 160914 20:16:58 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead. Sep 14 20:16:58 mail mysqld: 160914 20:16:58 [Note] Plugin 'FEDERATED' is disabled. Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: The InnoDB memory heap is disabled Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Mutexes and rw_locks use GCC atomic builtins Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Compressed tables use zlib 1.2.7 Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Using Linux native AIO Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Initializing buffer pool, size = 128.0M Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Completed initialization of buffer pool Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: highest supported file format is Barracuda. Sep 14 20:16:58 mail mysqld: InnoDB: Log scan progressed past the checkpoint lsn 38268393036 Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Database was not shut down normally! Sep 14 20:16:58 mail mysqld: InnoDB: Starting crash recovery. Sep 14 20:16:58 mail mysqld: InnoDB: Reading tablespace information from the .ibd files... Sep 14 20:16:58 mail mysqld: InnoDB: Restoring possible half-written data pages from the doublewrite Sep 14 20:16:58 mail mysqld: InnoDB: buffer... Sep 14 20:16:58 mail mysqld: InnoDB: Doing recovery: scanned up to log sequence number 38268412215 Sep 14 20:16:58 mail mysqld: InnoDB: Error: trying to access page number 66783441 in space 0, Sep 14 20:16:58 mail mysqld: InnoDB: space name ./ibdata1, Sep 14 20:16:58 mail mysqld: InnoDB: which is outside the tablespace bounds. Sep 14 20:16:58 mail mysqld: InnoDB: Byte offset 0, len 16384, i/o type 10. Sep 14 20:16:58 mail mysqld: InnoDB: If you get this error at mysqld startup, please check that Sep 14 20:16:58 mail mysqld: InnoDB: your my.cnf matches the ibdata files that you have in the Sep 14 20:16:58 mail mysqld: InnoDB: MySQL server. Sep 14 20:16:58 mail mysqld: 160914 20:16:58 InnoDB: Assertion failure in thread 139633171273504 in file fil0fil.c line 4578 Sep 14 20:16:58 mail mysqld: InnoDB: We intentionally generate a memory trap. Sep 14 20:16:58 mail mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Sep 14 20:16:58 mail mysqld: InnoDB: If you get repeated assertion failures or crashes, even Sep 14 20:16:58 mail mysqld: InnoDB: immediately after the mysqld startup, there may be Sep 14 20:16:58 mail mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to Sep 14 20:16:58 mail mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html Sep 14 20:16:58 mail mysqld: InnoDB: about forcing recovery. Sep 14 20:16:58 mail mysqld: 18:16:58 UTC - mysqld got signal 6 ; Sep 14 20:16:58 mail mysqld: This could be because you hit a bug. It is also possible that this binary Sep 14 20:16:58 mail mysqld: or one of the libraries it was linked against is corrupt, improperly built, Sep 14 20:16:58 mail mysqld: or misconfigured. This error can also be caused by malfunctioning hardware. Sep 14 20:16:58 mail mysqld: We will try our best to scrape up some info that will hopefully help Sep 14 20:16:58 mail mysqld: diagnose the problem, but since we have already crashed, Sep 14 20:16:58 mail mysqld: something is definitely wrong and this may fail. Sep 14 20:16:58 mail mysqld: Sep 14 20:16:58 mail mysqld: key_buffer_size=16777216 Sep 14 20:16:58 mail mysqld: read_buffer_size=131072 Sep 14 20:16:58 mail mysqld: max_used_connections=0 Sep 14 20:16:58 mail mysqld: max_threads=151 Sep 14 20:16:58 mail mysqld: thread_count=0 Sep 14 20:16:58 mail mysqld: connection_count=0 Sep 14 20:16:58 mail mysqld: It is possible that mysqld could use up to Sep 14 20:16:58 mail mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 K bytes of memory Sep 14 20:16:58 mail mysqld: Hope that's ok; if not, decrease some variables in the equation. Sep 14 20:16:58 mail mysqld: Sep 14 20:16:58 mail mysqld: Thread pointer: 0x0 Sep 14 20:16:58 mail mysqld: Attempting backtrace. You can use the following information to find out Sep 14 20:16:58 mail mysqld: where mysqld died. If you see no messages after this, something went Sep 14 20:16:58 mail mysqld: terribly wrong... Sep 14 20:16:58 mail mysqld: stack_bottom = 0 thread_stack 0x30000 Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x29)[0x56116275d809] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x561162644788] Sep 14 20:16:58 mail mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7efee15180a0] Sep 14 20:16:58 mail mysqld: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7efedfda7125] Sep 14 20:16:58 mail mysqld: /lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7efedfdaa3a0] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x647f72)[0x561162867f72] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x623a99)[0x561162843a99] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x62442c)[0x56116284442c] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x614f86)[0x561162834f86] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5f20df)[0x5611628120df] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5e78c4)[0x5611628078c4] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5e862c)[0x56116280862c] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5e9f9a)[0x561162809f9a] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5d76e2)[0x5611627f76e2] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x5a399f)[0x5611627c399f] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x561162646b11] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x3339e7)[0x5611625539e7] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0xa73)[0x561162556a63] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x2b97c5)[0x5611624d97c5] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x45b)[0x5611624da43b] Sep 14 20:16:58 mail mysqld: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7efedfd93ead] Sep 14 20:16:58 mail mysqld: /usr/sbin/mysqld(+0x2b15d9)[0x5611624d15d9] Sep 14 20:16:58 mail mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains Sep 14 20:16:58 mail mysqld: information that should help you find out what is causing the crash. Sep 14 20:16:58 mail mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended Sep 14 20:17:01 mail /USR/SBIN/CRON[7435]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Sep 14 20:17:12 mail /etc/init.d/mysql[7582]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in Sep 14 20:17:12 mail /etc/init.d/mysql[7582]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed Sep 14 20:17:12 mail /etc/init.d/mysql[7582]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)' Sep 14 20:17:12 mail /etc/init.d/mysql[7582]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! Sep 14 20:17:12 mail /etc/init.d/mysql[7582]:

Hat da jemand eine Idee was da falsch läuft?

Hab mittlerweile das Backup von gestern wiederhergestellt.
Nun läuft zwar wieder der mysql aber ich erhalte in der server.log ständig folgendes:

Wed Sep 14 22:25:15 2016: [error ] ECDatabaseMySQL::_Update() query failed Wed Sep 14 22:25:15 2016: [error ] ECDatabaseMySQL::Connect(): mysql connect fail 80000007

und beim Einlogg im webaccess kommt:

Unknown MAPI Error: MAPI_E_DISK_ERROR

Bitte um sachdienliche Hinweise, wir würden morgen gerne wieder arbeiten können :wink:

LG mandelbrot

Moin,

wie haben Sie die Backups denn erstellt? Als Dumps mit mysqldump? Oder einfach nur die Datendateien von MySQL wegkopiert?

Was passiert, wenn Sie jetzt versuchen, alle DBs mit »mysqldump« zu sichern (z.B. »mysqldump --opt --all-databases --single-transaction -u root -h localhost -p > /dev/null«)? Funktioniert das, oder bricht das irgendwo ab, falls ja, mit welcher Fehlermeldung?

Gruß,
mosu

Mastodon