DROP DATABASE crash mysql server

I have a little problem when I want to DROP my database.

When I execute:

DROP DATABASE `mydb`; 

MySQL returns:

 Error Code: 2013. Lost connection to MySQL server during query 

(Done from phpmyadmin, I am disconnected and redirected to login / password)

The problem may be a fantom table.

If I do:

 CHECK TABLE `mydb`.`mytable` 

I have:

 Error Code: 1146. Table 'mydb.mytable' doesn't exist 

But if I do:

 CREATE TABLE IF NOT EXISTS `mydb`.`mytable` ... 

I have:

 Error Code: 1050. Table '`mydb`.`mytable`' already exists 

"SELECT *" says this does not exist.

I tried innodb_force_recovery 6 when I execute DROP DATABASE:

 InnoDB: Load table 'mydb/mytable' failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.140417 11:09:55 InnoDB: Assertion failure in thread 2797190000 in file row0mysql.c line 3683 InnoDB: Failing assertion: table InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://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: http://dev.mysql.com/doc/refman/5.5/...-recovery.html InnoDB: about forcing recovery. 09:09:55 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=16777216 read_buffer_size=131072 max_used_connections=1 max_threads=151 thread_count=1 connection_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346075 K bytes of memory Hope that ok; if not, decrease some variables in the equation. Thread pointer: 0xffffffffb9523670 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 = ffffffffa6b9b32c thread_stack 0x30000 /usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb7329743] /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0xb71ca984] [0xb6e7f400] /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182)[0xb6b8bd72] /usr/sbin/mysqld(+0x4e1e3b)[0xb737fe3b] /usr/sbin/mysqld(+0x4c8d6a)[0xb7366d6a] /usr/sbin/mysqld(+0x32ca05)[0xb71caa05] /usr/sbin/mysqld(_Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_+0x1d1)[0xb70ac121] /usr/sbin/mysqld(_Z16ha_drop_databasePc+0x3f)[0xb71cbb9f] /usr/sbin/mysqld(_Z11mysql_rm_dbP3THDPcbb+0xc13)[0xb707b073] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4477)[0xb709fff7] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x254)[0xb70a2f54] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2000)[0xb70a5910] /usr/sbin/mysqld(_Z10do_commandP3THD+0xce)[0xb70a63de] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x123)[0xb7155983] /usr/sbin/mysqld(handle_one_connection+0x50)[0xb7155ab0] /lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x5c39)[0xb6e5dc39] /lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xb6c34d4e] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (ffffffffb9599500): DROP DATABASE `mydb` Connection ID (thread ID): 2 Status: NOT_KILLED 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. 

Ideas?

+7
mysql
source share
2 answers

The data file or the .frm file may have disappeared.

0
source share

Please check the max_allowed_packet value inside my.ini for Windows and my.cnf for Linux and increase the value, then restart the service for it to take effect. this should solve the problem.

-one
source share

All Articles