2013-08-12 7 views
6

Mam pustą bazę danych, której nie mogę upuścić. Początkowo zawierał tabelę, której nie mogłem wybrać. Więc DROP'ed wszystkie tabele z tej bazy danych i starał się usunąć bazę danych bez powodzenia:"ERROR 2013 (HY000): Utracono połączenie z serwerem MySQL podczas zapytania" podczas usuwania bazy danych

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

Teraz mam pustą bazę danych, że nie można usunąć w moim serwerze.

sprawdzić error.log mysql, tu jest wyjście:

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) 

próbowałem umieścić konfigurację innodb_force_recovery = 4 i ponownie MySQL, ale to nie miało wpływu w ogóle.

Ponowna instalacja serwera nie jest tutaj dostępna. Stało się tak na wielu komputerach (2 Ubuntu i 2 CentOS), ale nie mogę odtworzyć problemu już teraz.

+2

Sprawdź to: - http://dba.stackexchange.com/questions/35959/error-when-dropping-innodb-database –

+0

Wygląda na to, że jest to błąd. A ponieważ MySQL przechowuje całe dane InnoDB w jednym miejscu, wątpię, aby było możliwe, że można to rozwiązać za pomocą operacji na systemie plików. Wznów: nie będziesz w stanie robić tego –

Odpowiedz

1

Uważam, że ma to związek z korupcją tabeli InnoDB. Ja też miałem podobny problem i udało mi się go wskazać na jednej tabeli. Nadal jestem w trakcie korygowania problemu poprzez duplikowanie tabeli i usuwanie pojedynczego rekordu, który jest zły w moim przypadku.

Ten link pomógł mi znacznie:

Recovering InnoDB Table Corruption

Przepraszamy za niepełną odpowiedź, ale to pomogło mi trochę raz znalazłem go.

Powiązane problemy