2013-08-12 30 views
6

Tôi có một cơ sở dữ liệu trống mà tôi không thể thả. Ban đầu, nó chứa một bảng mà tôi không thể SELECT từ đó. Vì vậy, tôi DROP'ed tất cả các bảng từ cơ sở dữ liệu đó và cố gắng để DROP cơ sở dữ liệu mà không thành công:"ERROR 2013 (HY000): Mất kết nối với máy chủ MySQL trong khi truy vấn" trong khi thả cơ sở dữ liệu

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

Bây giờ tôi có một cơ sở dữ liệu trống mà tôi không thể loại bỏ trong máy chủ của tôi.

tôi kiểm tra error.log mysql, đây là kết quả:

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) 

Tôi cố gắng để đặt cấu hình innodb_force_recovery = 4 và khởi động lại MySQL nhưng nó không ảnh hưởng gì cả.

Cài đặt lại máy chủ không phải là một tùy chọn ở đây. Nó xảy ra trên nhiều máy (2 Ubuntu và 2 CentOS), nhưng tôi không thể tái tạo vấn đề ngay bây giờ.

+2

Kiểm tra điều này: - http://dba.stackexchange.com/questions/35959/error-when-dropping-innodb-database –

+0

Dường như đây là lỗi. Và, vì MySQL lưu trữ toàn bộ dữ liệu InnoDB trong một không gian, tôi nghi ngờ rằng điều này có thể được giải quyết thông qua các hoạt động của hệ thống tệp. Tiếp tục: bạn sẽ không thể thực hiện công cụ –

Trả lời

1

Tôi tin rằng nó có liên quan đến tham nhũng bảng InnoDB. Tôi cũng đã có một vấn đề tương tự và có thể xác định nó vào một bảng duy nhất. Tôi vẫn đang trong quá trình điều chỉnh vấn đề thông qua nhân bản bảng và xóa bản ghi duy nhất có hại trong trường hợp của tôi.

Liên kết này đã giúp tôi đáng kể:

Recovering InnoDB Table Corruption

Xin lỗi vì câu trả lời không đầy đủ, nhưng điều này đã giúp tôi khá nhiều lần tôi tìm thấy nó.

Các vấn đề liên quan