Tham nhũng MySQL INNODB sau sự cố máy chủ trong khi cắt lệnh đồng thời


9

Máy chủ của tôi bị sập hôm nay tôi nghĩ do lệnh cắt bảng đồng thời trên một trong các bảng INNODB của chúng tôi. Máy chủ có thể được khởi động lại, nhưng sau khi khởi động, mỗi lần tôi thử đưa ra lệnh SQL, tôi gặp lỗi sau:

ERROR 2006 (HY000): MySQL server has gone away

Đây là những gì đã xảy ra trong nhật ký:

121206 01:11:12  mysqld restarted
121206  1:11:13  InnoDB: Started; log sequence number 275 559321759
InnoDB: !!! innodb_force_recovery is set to 1 !!!
121206  1:11:13 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.95-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution
InnoDB: Error: trying to load index PRIMARY for table 
InnoDB: but the index tree has been freed!
121206  1:11:37 - mysqld got signal 11 ;
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=134217728
read_buffer_size=1048576
max_used_connections=1
max_connections=400
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 950272 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x9900950
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...
Cannot determine thread, fp=0x46353fa0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x9900950 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x993e500 =
thd->thread_id=1
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.

Tôi đã tìm kiếm trực tuyến và tôi nhận được gợi ý đó là lỗi của MySQL, nhưng tôi không biết làm thế nào để giải quyết nó. Tôi đang sử dụng phiên bản MySQL 5.0.95.

Có vẻ như tôi phải tạo một cơ sở dữ liệu mới và chuyển dữ liệu cũ sang cơ sở dữ liệu mới, nhưng làm thế nào tôi có thể làm điều đó nếu tôi thậm chí không thể đưa ra bất kỳ lệnh SQL nào cho cơ sở dữ liệu hiện tại?

--- CẬP NHẬT ---
Phiên bản: socket 5.0.95-log ':' /var/lib/mysql/mysql.sock 'port: 3306 Phân phối nguồn InnoDB: Lỗi: cố gắng tải chỉ mục PRIMARY cho bảng InnoDB: nhưng cây chỉ mục đã được giải phóng! 121206 4:13:41 - mysqld nhận được tín hiệu 11; Điều này có thể là do bạn gặp một lỗi. Cũng có thể nhị phân này hoặc một trong các thư viện mà nó được liên kết chống lại bị hỏng, được xây dựng không đúng hoặc bị định cấu hình sai. Lỗi này cũng có thể được gây ra bởi phần cứng bị trục trặc. Chúng tôi sẽ cố gắng hết sức để tìm ra một số thông tin hy vọng sẽ giúp chẩn đoán vấn đề, nhưng vì chúng tôi đã gặp sự cố, nên có gì đó không ổn và điều này có thể thất bại.

key_buffer_size=134217728
read_buffer_size=1048576
max_used_connections=1
max_connections=400
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 950272 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x17fb8950
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...
Cannot determine thread, fp=0x464a3fa0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x17fb8950 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x17ff6500 =
thd->thread_id=3
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.

Number of processes running now: 0
121206 04:13:41  mysqld restarted
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
121206  4:13:42  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
121206  4:13:43  InnoDB: Started; log sequence number 275 559323148
121206  4:13:43 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.95-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Câu trả lời:


6

NHIỆM VỤ # 1

Điều đầu tiên khiến tôi chú ý là dòng này

InnoDB: Lỗi: cố gắng tải chỉ mục PRIMARY cho bảng /

Điều này cho biết bạn có một bảng bằng cách sử dụng Công cụ lưu trữ InnoDB

Điều thú vị về InnoDB là cách lưu trữ KHÓA CHÍNH. Nó được lưu trữ trong một cấu trúc được gọi là gen_clust_index , hay thường được gọi là Chỉ mục cụm.

Tôi đoán ngay lập tức là một mục CHÍNH HÃNG nhất định là quá lớn

Vui lòng xem xét một số bài viết về mặt tốt, mặt xấu và xấu của việc sử dụng các phím CHÍNH HÃNG dài:

sau đó xem nếu <DB Hidden>.<Table Hidden>cần phải được thiết kế lại.

NHIỆM VỤ # 2

Xét về phỏng đoán của bạn liên quan đến một bảng cắt ngắn song song, điều đó nghe có vẻ nguy hiểm. Tại sao? InnoDB thực hiện BẢNG TRUNCATE là DDLkhông DML. Tôi đã viết về điều này trước đây:

NHIỆM VỤ # 3

Một số gợi ý điều chỉnh

Vui lòng thêm vào như sau my.ini

[mysqld]
max_allowed_packet=1G
innodb_fast_shutdown=0

Bắt đầu mysql

Trong một phiên khác, hãy chạy tail -f <errorlogfile>và xem InnoDB Crash Recovery.

Nếu mysql được khởi động hoàn toàn sao lưu và khôi phục sự cố InnoDB đã hoàn tất, hãy thử tắt mysql ngay lập tức. Bạn có thể cần thay đổi kích thước Nhật ký giao dịch InnoDB của mình.

Xin lỗi vì những lời đề nghị hoang dã này, nhưng tôi đang bay mù ở đây.

Xin vui lòng gửi sau đây trong câu hỏi:

  • hoàn toàn của bạn my.cnf
  • có bao nhiêu RAM trên tàu

CẬP NHẬT 2012-12-05 12:09 EDT

Hãy làm như sau:

BƯỚC 01) Thêm những thay đổi này vào my.cnf

[mysqld]
max_allowed_packet=1G
innodb_fast_shutdown=0
innodb_thread_concurrency=0

BƯỚC 02) service mysql restart

để đảm bảo mysql xuất hiện

BƯỚC 03) Bạn cần thay đổi kích thước ib_logfile0 và ib_logfile1 (24M có thể quá nhỏ)

service mysql stop
cd /var/lib/mysql
mv ib_logfile0 ib_logfile0.bak
mv ib_logfile1 ib_logfile1.bak

BƯỚC 04) Thêm những thay đổi này vào my.cnf

[mysqld]
innodb_log_file_size=512M
innodb_log_buffer_size=8M

BƯỚC 05) service mysql start

mysqld sẽ tạo lại ib_logfile0 và ib_logfile1 512M mỗi cái

Bây giờ, hãy thử và xem những gì xảy ra ....

CẬP NHẬT 2012-12-05 12:18 EDT

Trong thời gian chờ đợi, vui lòng đọc bài đăng trên ServerFault của tôi trên gói mysql và hàm ý kích thước của nó liên quan đến innodb_log_file_sizeinnodb_log_buffer_size khi tôi học được từ bài đăng trên ServerFault của người khác .

CẬP NHẬT 2012-12-05 14:28 EDT

Tôi đã chỉnh sửa tất cả các tham chiếu đến các bảng khách hàng trong câu hỏi này.

Nguyên nhân gốc là một trang bị hỏng ibdata1với dữ liệu và trang chỉ mục được trộn lẫn bên trong. Tôi đã giúp Andrew di chuyển dữ liệu ra, tạo lại ibdata1 bằng innodb_file_per_table và Andrew tải lại dữ liệu.


Cảm ơn ý kiến ​​của bạn Rolando. Tôi chắc chắn sẽ xem xét lại cấu trúc của khóa chính. Trong khi đó, tôi sẽ xem qua các bài viết của bạn và xem liệu tôi có thể lấy lại máy chủ của chúng tôi và chạy ASAP không.
Andrew

Một số phần của ibdata1 có một trang bị hỏng. Tôi đã thấy tình trạng này nhiều lần với các khách hàng lưu trữ của tôi.
RolandoMySQLDBA


Theo yêu cầu, tôi xóa sạch tất cả các bình luận của mình để che giấu thông tin nhạy cảm.
RolandoMySQLDBA

@RolandoMySQLDBA, bạn có thể giải thích làm thế nào bạn phát hiện ra nguyên nhân gốc rễ, ý tôi là làm thế nào bạn tìm ra điều này? Và những bước bạn đã làm để khắc phục điều này?
Bhupesh Pant
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.