2013-08-12 19 views
6

Ho un database vuoto che non posso rilasciare. Inizialmente, conteneva una tabella da cui non potevo selezionare. Così ho DROP'ed tutte le tabelle da quel database e ha cercato di cancellare il database senza successo:"ERRORE 2013 (HY000): connessione persa al server MySQL durante la query" durante il rilascio del database

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

ora ho un database vuoto che non riesco a rimuovere in mio assistente.

ho controllare l'error.log mysql, ecco l'output:

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) 

ho cercato di mettere la configurazione innodb_force_recovery = 4 e riavviare MySQL, ma non ha avuto alcun effetto a tutti.

La reinstallazione del server non è un'opzione qui. È successo su molte macchine (2 Ubuntu e 2 CentOS), ma al momento non riesco a riprodurre il problema.

+2

Controlla questo: http://dba.stackexchange.com/questions/35959/error-when-dropping-innodb-database –

+0

Sembra un bug. E dato che MySQL memorizza interi dati InnoDB in uno spazio, dubito che sia possibile risolverlo tramite le operazioni del file system. Riprendi: non sarai in grado di fare le cose –

risposta

1

Credo che abbia a che fare con la corruzione della tabella InnoDB. Anch'io ho avuto un problema simile ed è stato in grado di individuarlo in un unico tavolo. Sono ancora in procinto di correggere il problema attraverso la duplicazione della tabella e la rimozione del singolo record che è male nel mio caso.

Questo link mi ha aiutato in modo significativo:

Recovering InnoDB Table Corruption

Scusate risposta incompleta, ma questo mi ha aiutato un po ', una volta l'ho trovato.

Problemi correlati