Bảng InnoDB SELECT trả về ERROR 2006 (HY000): Máy chủ MySQL đã biến mất (sau khi mất điện)

Máy chủ này là một máy ảo chạy CentOS 6.0, MySQL 5.5.21

Có một cơ sở dữ liệu được đặt tên devSystem. Có bảng InnoDB trong. Chạy các lệnh sau gây ra lỗi ERROR 2006 (HY000): MySQL server has gone away. Trước đây tôi chưa sử dụng InnoDB rộng rãi và do đó chưa gặp phải loại vấn đề này. Tôi chỉ có thể giả sử nó cụ thể với InnoDB vì nó chưa nổi lên bằng MyISAM. Dù sao, các lệnh tôi cố gắng chạy như sau.

mysql -u root -p
mysql> USE `devSystem`;
-- database changed
mysql> SHOW TABLES;

Lỗi đầy đủ do máy khách MySQL trả về

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
ERROR:
Can't connect to the server

Bây giờ đang cố gắng CHỌN từ bảng basketstồn tại trongdevSystem

mysql> select * from baskets\G
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
ERROR:
Can't connect to the server

Để so sánh, tôi đã thử một cơ sở dữ liệu thứ hai cũng có các bảng InnoDB trên cùng một máy chủ

mysql> USE `testSystem`;
-- database changed
mysql> SHOW TABLES;

Điều này xuất ra các bảng chính xác. Vì lý do này, tôi cho rằng đó là một vấn đề devSystemcụ thể.

Tôi đã thử tìm kiếm ở đây tuy nhiên các truy vấn tương tự khác dường như không hữu ích, có ai có bất kỳ đề xuất / lời khuyên nào sẽ giúp tôi giải quyết vấn đề này không? Điều này đã lãng phí cả buổi sáng của tôi!

Các tùy chọn hiện tại dường như là xóa cơ sở dữ liệu và bắt đầu lại (tuy nhiên sẽ mất một lượng công việc đáng kể. Tôi có một thiết kế cơ sở dữ liệu gần như hiện tại tuy nhiên không có bản sao lưu dữ liệu đã được tạo cho đến nay)

cập nhật 1 Thêm innodb_force_recovery = 6vào my.cnfcho phép SHOW TABLE STATUSthực thi thành công, các giá trị <= 5 vẫn dẫn đến lỗi như được hiển thị ở trên. Với cờ này SELECT * FROM basketshoạt động, tuy nhiên một bảng đặc biệt có lỗi trả về vẫn chỉ ra đó là một bảng có thể gây ra sự cố?

mysql> SELECT * FROM supplierOptionalExtras_relationships;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: devSystem

ERROR 2013 (HY000): Lost connection to MySQL server during query

PHẦN KẾT LUẬN

Cuối cùng sau nhiều giờ quét qua các tập tin khôi phục, tôi chỉ có thể kết luận rằng dữ liệu của mình đã bị mất (như RolandoMyQueryDBA đã nói). Để đi xa như tôi đã làm theo đề xuất của DTest trên Công cụ khôi phục Percona, tuy nhiên việc hỏng dữ liệu có nghĩa là các công cụ không thể trích xuất dữ liệu từ ibdata1tệp của tôi cho bảng cụ thể.

Cuối cùng, tôi đã sử dụng câu trả lời của RolandoMySQLDBA và đã làm như sau

1. Làm theo hướng dẫn tại đây /programming/3927690/howto-clean-a-mysql-innodb-st Storage-engine / 4056261 # 4056261 không bao gồm cơ sở dữ liệu bị sập
2. Được sử dụng innodb_force_recovery = 6để lấy tất cả dữ liệu bảng không bị lỗi từ cơ sở dữ liệu với bảng bị hỏng
3. Tắt MySQl, xóa innodb_force_recovery = 6, xóa các tệp ibdata / iblog (như chi tiết trong liên kết ở bước 1)
4. Bắt đầu MySQL và tải dữ liệu bị đổ
5. Bảng xấu được tái tạo từ các tập tin thiết kế
6. Dữ liệu được phục hồi thủ công

Tất nhiên, điều này có nghĩa là mất toàn bộ dữ liệu từ bảng bị ảnh hưởng, tuy nhiên tôi chỉ có thể hy vọng rằng việc thêm innodb_file_per_tablesẽ giúp phục hồi dữ liệu nếu điều này tái diễn - tôi dự định sẽ giết điện vào một lúc nào đó để thử và tái tạo điều này trong thử nghiệm cơ sở dữ liệu.

Dưới đây là một số thông tin dài dòng từ các bản ghi.

my.cnf

Đây chỉ là một hệ thống dev nên my.cnf là RẤT cơ bản, trên thực tế không thay đổi so với mặc định

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Nhật ký MySQL từ máy chủ bắt đầu trước khi không thực hiện được truy vấn

120302 10:57:42 [Note] /usr/libexec/mysqld: Normal shutdown

120302 10:57:42 [Note] Event Scheduler: Purging the queue. 0 events
120302 10:57:42  InnoDB: Starting shutdown...
120302 10:57:42  InnoDB: Shutdown completed; log sequence number 285938465
120302 10:57:42 [Note] /usr/libexec/mysqld: Shutdown complete

120302 10:57:42 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120302 10:57:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120302 10:57:43 [Note] Plugin 'FEDERATED' is disabled.
120302 10:57:43 InnoDB: The InnoDB memory heap is disabled
120302 10:57:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:57:43 InnoDB: Compressed tables use zlib 1.2.3
120302 10:57:43 InnoDB: Using Linux native AIO
120302 10:57:43 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:57:43 InnoDB: Completed initialization of buffer pool
120302 10:57:43 InnoDB: highest supported file format is Barracuda.
120302 10:57:43  InnoDB: Waiting for the background threads to start
120302 10:57:44 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:57:44 [Note] Event Scheduler: Loaded 0 events
120302 10:57:44 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi

Hàng đăng nhập MySQL sau truy vấn không thành công

120302 10:58:39  InnoDB: Assertion failure in thread 140030446421760 in file btr0btr.c line 695
InnoDB: Failing assertion: (ibool)!!page_is_comp(buf_block_get_frame(block)) == dict_table_is_comp(index->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.
120302 10:58:39 - 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=8388608
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 = 338483 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x30396e0
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 = 0x7f5b61043d98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x33)[0x77b6e3]
/usr/libexec/mysqld(handle_segfault+0x465)[0x50fc35]
/lib64/libpthread.so.0[0x37a9e0f4c0]
/lib64/libc.so.6(gsignal+0x35)[0x37a9a329a5]
/lib64/libc.so.6(abort+0x175)[0x37a9a34185]
/usr/libexec/mysqld[0x82a4bb]
/usr/libexec/mysqld[0x82a60c]
/usr/libexec/mysqld[0x85d133]
/usr/libexec/mysqld[0x862207]
/usr/libexec/mysqld[0x7e37a3]
/usr/libexec/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x3d)[0x66903d]
/usr/libexec/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x537)[0x5edf67]
/usr/libexec/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0xc33)[0x54d2d3]
/usr/libexec/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x683)[0x54e043]
/usr/libexec/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTj+0x4b)[0x54e61b]
/usr/libexec/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x23)[0x5c5623]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x174f)[0x581f2f]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0xd2)[0x60e9e2]
/usr/libexec/mysqld(handle_one_connection+0x50)[0x60eaf0]
/lib64/libpthread.so.0[0x37a9e077e1]
/lib64/libc.so.6(clone+0x6d)[0x37a9ae18ed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f5b50004c20): is an invalid pointer
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.
120302 10:58:39 mysqld_safe Number of processes running now: 0
120302 10:58:39 mysqld_safe mysqld restarted
120302 10:58:39 [Note] Plugin 'FEDERATED' is disabled.
120302 10:58:39 InnoDB: The InnoDB memory heap is disabled
120302 10:58:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:58:39 InnoDB: Compressed tables use zlib 1.2.3
120302 10:58:39 InnoDB: Using Linux native AIO
120302 10:58:39 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:58:39 InnoDB: Completed initialization of buffer pool
120302 10:58:39 InnoDB: highest supported file format is Barracuda.
120302 10:58:39  InnoDB: Waiting for the background threads to start
120302 10:58:40 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:58:40 [Note] Event Scheduler: Loaded 0 events
120302 10:58:40 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
120302 10:58:47  InnoDB: Assertion failure in thread 140051237820160 in file btr0btr.c line 695
InnoDB: Failing assertion: (ibool)!!page_is_comp(buf_block_get_frame(block)) == dict_table_is_comp(index->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.
120302 10:58:47 - 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=8388608
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 = 338483 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x231b6e0
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 = 0x7f603847cd98 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x33)[0x77b6e3]
/usr/libexec/mysqld(handle_segfault+0x465)[0x50fc35]
/lib64/libpthread.so.0[0x37a9e0f4c0]
/lib64/libc.so.6(gsignal+0x35)[0x37a9a329a5]
/lib64/libc.so.6(abort+0x175)[0x37a9a34185]
/usr/libexec/mysqld[0x82a4bb]
/usr/libexec/mysqld[0x82a60c]
/usr/libexec/mysqld[0x85d133]
/usr/libexec/mysqld[0x862207]
/usr/libexec/mysqld[0x7e37a3]
/usr/libexec/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x3d)[0x66903d]
/usr/libexec/mysqld(_Z21open_table_from_shareP3THDP11TABLE_SHAREPKcjjjP5TABLEb+0x537)[0x5edf67]
/usr/libexec/mysqld(_Z10open_tableP3THDP10TABLE_LISTP11st_mem_rootP18Open_table_context+0xc33)[0x54d2d3]
/usr/libexec/mysqld(_Z11open_tablesP3THDPP10TABLE_LISTPjjP19Prelocking_strategy+0x683)[0x54e043]
/usr/libexec/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTj+0x4b)[0x54e61b]
/usr/libexec/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x23)[0x5c5623]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x174f)[0x581f2f]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0xd2)[0x60e9e2]
/usr/libexec/mysqld(handle_one_connection+0x50)[0x60eaf0]
/lib64/libpthread.so.0[0x37a9e077e1]
/lib64/libc.so.6(clone+0x6d)[0x37a9ae18ed]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f6014004c20): is an invalid pointer
Connection ID (thread ID): 1
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.
120302 10:58:47 mysqld_safe Number of processes running now: 0
120302 10:58:47 mysqld_safe mysqld restarted
120302 10:58:47 [Note] Plugin 'FEDERATED' is disabled.
120302 10:58:47 InnoDB: The InnoDB memory heap is disabled
120302 10:58:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120302 10:58:47 InnoDB: Compressed tables use zlib 1.2.3
120302 10:58:47 InnoDB: Using Linux native AIO
120302 10:58:47 InnoDB: Initializing buffer pool, size = 128.0M
120302 10:58:47 InnoDB: Completed initialization of buffer pool
120302 10:58:47 InnoDB: highest supported file format is Barracuda.
120302 10:58:47  InnoDB: Waiting for the background threads to start
120302 10:58:48 InnoDB: 1.1.8 started; log sequence number 285938465
120302 10:58:48 [Note] Event Scheduler: Loaded 0 events
120302 10:58:48 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.15'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi

Điều này có vẻ kỳ lạ quen thuộc.

Tôi đã thấy điều này xảy ra với một trong các máy chủ DB của máy khách lưu trữ web của tôi. Có một bảng đặc biệt đã bị sập mysqld mỗi khi bạn truy cập nó, ngay cả với SHOW CREATE TABLE.

Vấn đề bắt nguồn từ một từ điển dữ liệu bị hỏng. Thực sự không có cách nào để sửa nó. Bạn có thể cố gắng thay đổi framespace_id trong tệp .ibd nhưng vấn đề đau đầu bắt nguồn từ việc định vị danh sách framespace_id bên trong thành ibdata1.

Ngay cả khi bạn tạo bảng MyISAM có cùng tên trong cùng cơ sở dữ liệu với bảng InnoDB ban đầu, bạn không thể chuyển đổi nó thành InnoDB vì bảngpace_id đã được liên kết với tên bảng. Điều này, tất nhiên, là một trạng thái bị hỏng. Nó giống như có một lỗ cháo trong ibdata1 mà bạn không thể vá mà không cần phẫu thuật thăm dò.

Bạn có thể phải mysqldump tất cả mọi thứ trừ cơ sở dữ liệu chứa bảng bị hỏng. Sau đó, bạn sẽ phải mysqldump mỗi bảng trong cơ sở dữ liệu đó ngoại trừ bảng bị hỏng. Hãy nhớ rằng, đó là chế độ xem từ điển dữ liệu của bảng được vặn lên, không nhất thiết là dữ liệu của bảng.

Cách chắc chắn duy nhất để dọn dẹp mọi thứ là thực hiện mysqldumps như tôi vừa chỉ định, tắt mysql, rm -rf tất cả các thư mục DB ngoại trừ / var / lib / mytsql / mysql, xóa ibdata1, xóa ib_logfile0, xóa ib_logfile1, khởi động lại mys_logfile1 tất cả mysqldumps. Xem bài đăng StackOverflow của tôi về việc dọn dẹp cơ sở hạ tầng InnoDB của bạn .

Vì bạn không sử dụng innodb_file_per_table, bất kỳ bảng nào có trạng thái tham nhũng này trong ibdata1 đều bị mất vì thương vong của chiến tranh. Gửi lời chia buồn của tôi.

Để tham khảo trong tương lai, bấm vào đây để xem một khái niệm nghệ thuật về InnoDB và Nội bộ của nó .

Bạn dường như gặp phải trường hợp xấu nhất có thể xảy ra: Không gian bảng innodb bị hỏng mà không có bản sao lưu để khôi phục (có thể nhanh hơn nhiều).

Có một công cụ khôi phục innodb miễn phí được cung cấp bởi Percona và blog này hướng dẫn cách sử dụng nó để khôi phục dữ liệu bị hỏng của bạn mà không cần sao lưu.

Có một cảnh báo rất quan trọng này:

Thời gian giữa việc xóa các hàng và dừng cơ sở dữ liệu là rất quan trọng. Nếu các trang được sử dụng lại, bạn không thể khôi phục dữ liệu.

Thật không may, bạn sắp có được nhiều kinh nghiệm hơn trong việc sửa chữa innodb bị hỏng hơn cá nhân tôi từng làm.

dừng mysql:

/etc/init.d/mysql stop

bắt đầu mysql_safe:

mysql_safe &

có được giao diện điều khiển mysql như mọi cách:

mysql -u <user> -p bla bla bla or whatever

drop <conflicting-data-base>

kill mysql_safe

/etc/init.d/mysql start

và cố định cho tôi