2013-08-12 13 views
6

Ich habe eine leere Datenbank, die ich nicht fallen lassen kann. Anfangs enthielt es eine Tabelle, aus der ich nicht auswählen konnte. So DROP'ed ich alle Tabellen aus dieser Datenbank und versucht, die Datenbank ohne Erfolg auf DROP:"FEHLER 2013 (HY000): Verlorene Verbindung zum MySQL-Server während der Abfrage" beim Löschen der Datenbank

mysql> drop database my_database; 
ERROR 2013 (HY000): Lost connection to MySQL server during query 

Jetzt habe ich eine leere Datenbank, die ich nicht in meinem Server entfernen können.

ich die mysql error.log überprüfen, hier ist die Ausgabe:

130812 10:02:45 InnoDB: Assertion failure in thread 140409656780544 in file row0mysql.c line 3682 
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/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery. 
14:02:45 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=3 
max_threads=151 
thread_count=3 
connection_count=3 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346685 K bytes of memory 
Hope that's ok; if not, decrease some variables in the equation. 

Thread pointer: 0x7fb3ad55d030 
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 = 7fb3abb71e60 thread_stack 0x30000 
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7fb3ac1516b9] 
/usr/sbin/mysqld(handle_fatal_signal+0x3d8)[0x7fb3ac039318] 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7fb3aab96cb0] 
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7fb3aa1ff425] 
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7fb3aa202b8b] 
/usr/sbin/mysqld(+0x561acd)[0x7fb3ac192acd] 
/usr/sbin/mysqld(+0x542c63)[0x7fb3ac173c63] 
/usr/sbin/mysqld(+0x40837f)[0x7fb3ac03937f] 
/usr/sbin/mysqld(_Z24plugin_foreach_with_maskP3THDPFcS0_P13st_plugin_intPvEijS3_+0x165)[0x7fb3abf4daa5] 
/usr/sbin/mysqld(_Z11mysql_rm_dbP3THDPcbb+0x300)[0x7fb3abf23580] 
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x203c)[0x7fb3abf418ac] 
/usr/sbin/mysqld(+0x31301e)[0x7fb3abf4401e] 
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x19e7)[0x7fb3abf46247] 
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x105)[0x7fb3abfe0405] 
/usr/sbin/mysqld(handle_one_connection+0x50)[0x7fb3abfe0520] 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fb3aab8ee9a] 
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fb3aa2bcccd] 

Trying to get some variables. 
Some pointers may be invalid and cause the dump to abort. 
Query (7fb388004b90): is an invalid pointer 
Connection ID (thread ID): 59 
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. 
130812 10:02:45 [Note] Plugin 'FEDERATED' is disabled. 
130812 10:02:45 InnoDB: The InnoDB memory heap is disabled 
130812 10:02:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
130812 10:02:45 InnoDB: Compressed tables use zlib 1.2.7 
130812 10:02:45 InnoDB: Using Linux native AIO 
130812 10:02:45 InnoDB: Initializing buffer pool, size = 128.0M 
130812 10:02:45 InnoDB: Completed initialization of buffer pool 
130812 10:02:45 InnoDB: highest supported file format is Barracuda. 
130812 10:02:45 InnoDB: Waiting for the background threads to start 
130812 10:02:46 InnoDB: 5.5.32 started; log sequence number 25852489043 
130812 10:02:46 InnoDB: !!! innodb_force_recovery is set to 4 !!! 
130812 10:02:46 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306 
130812 10:02:46 [Note] - '127.0.0.1' resolves to '127.0.0.1'; 
130812 10:02:46 [Note] Server socket created on IP: '127.0.0.1'. 
130812 10:02:46 [Note] Event Scheduler: Loaded 0 events 
130812 10:02:46 [Note] /usr/sbin/mysqld: ready for connections. 
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu) 

Ich habe versucht, die Konfiguration innodb_force_recovery = 4 und starten Sie MySQL zu setzen, aber es hatte überhaupt keine Wirkung.

Die Neuinstallation des Servers ist hier nicht möglich. Es geschah auf vielen Rechnern (2 Ubuntu und 2 CentOS), aber ich kann das Problem jetzt nicht reproduzieren.

+2

Überprüfen Sie dies: - http://dba.stackexchange.com/questions/35959/error-when-dropping-innodb-database –

+0

Es scheint ein Fehler zu sein. Und da MySQL ganze InnoDB-Daten in einem Bereich speichert, bezweifle ich, dass dies möglicherweise über Dateisystemoperationen gelöst werden kann. Resume: Sie werden nicht in der Lage sein, das Zeug zu machen –

Antwort

1

Ich glaube, es hat mit InnoDB Tabelle Korruption zu tun. Ich hatte auch ein ähnliches Problem und konnte es an einem einzigen Tisch lokalisieren. Ich bin immer noch dabei, das Problem zu beheben, indem ich die Tabelle dupliziere und den einzelnen Datensatz lösche, der in meinem Fall schlecht ist.

Dieser Link hat mir geholfen, deutlich:

Recovering InnoDB Table Corruption

Sorry für unvollständige Antwort, aber das half mir ziemlich viel, wenn ich es gefunden.