2

Mysql can't start, here is the log :

150708 06:28:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150708  6:28:36 [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.
150708  6:28:36 [Note] /usr/libexec/mysqld (mysqld 5.5.43) starting as process 13122 ...
150708  6:28:36 [Note] Plugin 'FEDERATED' is disabled.
150708  6:28:36 InnoDB: The InnoDB memory heap is disabled
150708  6:28:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150708  6:28:36 InnoDB: Compressed tables use zlib 1.2.3
150708  6:28:36 InnoDB: Using Linux native AIO
150708  6:28:36 InnoDB: Initializing buffer pool, size = 128.0M
150708  6:28:36 InnoDB: Completed initialization of buffer pool
150708  6:28:36 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150708  6:28:36  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...
150708  6:28:36  InnoDB: Assertion failure in thread 140002885236704 in file fsp0fsp.c line 2102
InnoDB: Failing assertion: inode
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
04:28:36 UTC - mysqld got signal 6 
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail.

key_buffer_size=33554432
read_buffer_size=1048576
max_used_connections=0
max_threads=400
thread_count=0
connection_count=0

It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1266177 K bytes of memory.

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x78ca9e]
/usr/libexec/mysqld(handle_fatal_signal+0x493)[0x675553]
/lib64/libpthread.so.0(+0xf710)[0x7f54f5fc8710]
/lib64/libc.so.6(gsignal+0x35)[0x7f54f440e625]
/lib64/libc.so.6(abort+0x175)[0x7f54f440fe05]
/usr/libexec/mysqld[0x8a2f20]
/usr/libexec/mysqld[0x8a2fb2]
/usr/libexec/mysqld[0x8af255]
/usr/libexec/mysqld[0x87fc41]
/usr/libexec/mysqld[0x8309ba]
/usr/libexec/mysqld[0x7fc490]
/usr/libexec/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x6781a1]
/usr/libexec/mysqld[0x58e048]
/usr/libexec/mysqld(_Z11plugin_initPiPPci+0x928)[0x591c38]
/usr/libexec/mysqld[0x518568]
/usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x3fd)[0x51b72d]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f54f43fad5d]
/usr/libexec/mysqld[0x511335]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
150708 06:28:36 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
  • What are these varibles set to in your my.cnf? innodb_buffer_pool_instances=N innodb_buffer_pool_size=NNN – Craig Efrein Jul 8 '15 at 11:53
3

(!!! Make a backup first before trying the following !!!)

Step 1 : Setting in your ini file:

[mysqld]
innodb_force_recovery = 1

(Change your mysql port from 3306 to something else if you don't want clients to reconnect during your recovery)

https://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html

Step 2: Increase the number carefully until you have your database to start-up at least again.

Step 3: Try to figure out which table is corrupted:

mysqlcheck --port (newport) --all-databases

Step 4: Then dump your data/structure to recreate the corrupted table:

mysqldump my_database table > database.table.sql

Or ... if possible (not too much data), dump the whole database and recreate all.

Step 5: Restart your database, or a new/clean database in normal mode, and import your recovered data.

(when all is fixed, use the standard port again)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.