Mysql bị sập và sẽ không khởi động

Máy chủ mysql sản xuất của chúng tôi vừa gặp sự cố và sẽ không hoạt động trở lại. Đó là một lỗi segfault. Tôi đã thử khởi động lại và chỉ không biết nên thử cái gì khác. Đây là stacktrace:

140502 14:13:05 [Lưu ý] Plugin 'LIÊN KẾT' bị tắt.
InnoDB: Quét nhật ký đã vượt qua điểm kiểm tra lsn 108 1057948207
140502 14:13:06 InnoDB: Cơ sở dữ liệu không bị tắt bình thường!
InnoDB: Bắt đầu phục hồi sự cố.
InnoDB: Đọc thông tin không gian bảng từ các tệp .ibd ...
InnoDB: Khôi phục các trang dữ liệu nửa viết có thể từ doublewrite
InnoDB: bộ đệm ...
InnoDB: Đang thực hiện khôi phục: quét lên để đăng nhập số thứ tự 108 1058059648
InnoDB: 1 giao dịch phải được khôi phục hoặc dọn sạch
InnoDB: trong tổng số 15 hoạt động hàng để hoàn tác
InnoDB: Bộ đếm id Trx là 0 562485504
140502 14:13:06 InnoDB: Bắt đầu một loạt các bản ghi nhật ký áp dụng cho cơ sở dữ liệu ...
InnoDB: Tiến bộ về phần trăm: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 97 98 99 
InnoDB: Áp dụng lô hoàn thành
InnoDB: Bắt đầu từ nền tảng khôi phục các giao dịch không được cam kết
140502 14:13:06 InnoDB: Quay lại trx với id 0 562485192, 15 hàng để hoàn tác
140502 14:13:06 InnoDB: Bắt đầu; số thứ tự đăng nhập 108 1058059648
140502 14:13:06 InnoDB: Lỗi xác nhận trong luồng 1873206128 trong tệp ../../../st Storage /innobase / fsp / fsp0fsp.c dòng 1593
InnoDB: Không xác nhận: thất bại> 0
InnoDB: Chúng tôi cố tình tạo ra một cái bẫy bộ nhớ.
InnoDB: Gửi báo cáo lỗi chi tiết đến http://bugs.mysql.com.
InnoDB: Nếu bạn gặp sự cố hoặc sự cố xác nhận lặp đi lặp lại, thậm chí
InnoDB: ngay sau khi khởi động mysqld, có thể có
InnoDB: tham nhũng trong không gian bảng InnoDB. Vui lòng tham khảo trước
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: về việc buộc phục hồi.
140502 14:13:06 - mysqld có tín hiệu 6;
Điều này có thể là do bạn gặp một lỗi. Cũng có thể là nhị phân này
hoặc một trong những 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 cách,
hoặc 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 = 16777216
read_buffer_size = 131072
max_use_connections = 0
max_threads = 151
chủ đề_connected = 0
Có thể là mysqld có thể sử dụng tới 
key_buffer_size + (read_buffer_size + sort_buffer_size) * max_threads = 345919 K
byte bộ nhớ
Hy vọng là ok; nếu không, giảm một số biến trong phương trình.

thd: 0x0
Cố gắng quay lại. Bạn có thể sử dụng các thông tin sau để tìm hiểu
nơi mysqld chết. Nếu bạn không thấy tin nhắn nào sau đó, một cái gì đó đã đi
sai lầm khủng khiếp ...
stack_bottom = (nil) thread_stack 0x30000
140502 14:13:06 [Lưu ý] Trình lập lịch sự kiện: Đã tải 0 sự kiện
140502 14:13:06 [Lưu ý] / usr / sbin / mysqld: sẵn sàng cho các kết nối.
Phiên bản: ổ cắm '5.1.41-3ubfox12.10': '/var/run/mysqld/mysqld.sock' cổng: 3306 (Ubuntu)
/ usr / sbin / mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (xử lý_segfault + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74f4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_usiously + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (btr_discard_page + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xb7504771]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74c210f]
/ usr / sbin / mysqld (que_run_threads + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6d65a4e]
Trang hướng dẫn tại http://dev.mysql.com/doc/mysql/en/crashing.html chứa
thông tin sẽ giúp bạn tìm ra những gì gây ra vụ tai nạn.

Có khuyến nghị nào không?

Ôi.

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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

Kiểm tra trang web được đề xuất: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html .

Về cơ bản, hãy thử khởi động máy chủ MySQL ở chế độ khôi phục và tạo bản sao lưu các bảng bị hỏng của bạn .

Chỉnh sửa /etc/my.cnfvà thêm:

 innodb_force_recovery = 1

... Để xem liệu bạn có thể vào cơ sở dữ liệu của mình và lấy dữ liệu của bạn / tìm bảng bị hỏng không.

Thông thường, khi điều này xảy ra, đó là bản dựng lại (ít nhất là một hoặc hai bảng bị hỏng).

Từ http://chepri.com/mysql-innodb-corruption-and-recovery/ :

1. Dừng lại mysqld( service mysql stop).
2. Sao lưu /var/lib/mysql/ib*

3. Thêm dòng sau vào /etc/my.cnf:

   innodb_force_recovery = 1
   

   (họ đề xuất 4, nhưng tốt nhất là bắt đầu bằng 1 và tăng nếu không bắt đầu)

4. Khởi động lại mysqld( service mysql start).

5. Kết xuất tất cả các bảng: mysqldump -A > dump.sql
6. Bỏ tất cả các cơ sở dữ liệu cần phục hồi.
7. Dừng lại mysqld( service mysql stop).
8. Tẩy /var/lib/mysql/ib*
9. Nhận xét innodb_force_recoverytrong/etc/my.cnf
10. Khởi động lại mysqld. Nhìn vào nhật ký lỗi mysql. Theo mặc định, nó sẽ là /var/lib/mysql/server/hostname.com.errđể xem làm thế nào nó tạo ra các ib*tập tin mới .
11. Khôi phục cơ sở dữ liệu từ bãi chứa: mysql < dump.sql

Tôi đã phải đối mặt với lỗi tương tự trong khi sử dụng hình ảnh docker mysql: 5.7. Lỗi chính là cố gắng tạo người dùng root tồn tại theo mặc định. Thêm thông tin: https://github.com/docker-l Library / mysql /issues / 129

Như được đưa ra trong liên kết trên, giải pháp là KHÔNG đặt MYSQL_USER và MYSQL_PASSWORD trong các biến môi trường trong khi bắt đầu hình ảnh docker.

Điều này đã xảy ra với tôi trong Laravel Homestead (Vagrant sau khi nhân hoảng loạn chạy Mac OS Sierra 10.12.4 (16E195):

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

Dưới đây là một số tài nguyên bạn có thể thử, mặc dù không có tùy chọn sửa chữa nào phù hợp với tôi :

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-case-for-the-MyQuery-database

Tôi đã thử thêm phục hồi lực lượng vào cấu hình mysql (bắt đầu từ 1 và tăng dần lên vì số lượng được cho là cao hơn có thể gây ra tham nhũng vĩnh viễn):

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

Trong một cửa sổ khác, chạy:

tail -f /var/log/mysql/error.log

Sau đó thử khởi động lại mysqld với các tùy chọn khác nhau được bật:

sudo /etc/init.d/mysql restart

Nếu hết thời gian, bạn có thể buộc khởi động lại các quy trình mysql bằng:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

Nếu nó hoạt động, nhật ký sẽ hiển thị một cái gì đó như:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

Nếu thất bại, nhật ký sẽ hiển thị một cái gì đó như:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

Khi tệ hơn đến tồi tệ hơn, tôi đã cố gắng loại bỏ cơ sở dữ liệu có khả năng bị hỏng:

sudo ls -alt /var/lib/mysql

Hóa ra cơ sở dữ liệu mà tôi đang làm việc là cơ sở dữ liệu được sửa đổi gần đây nhất ở đầu danh sách. May mắn thay, tôi đã có một kết xuất SQL cho nó từ ngày đó vì vậy đã có thể loại bỏ nó:

sudo rm -rf /var/lib/mysql/<database_name>

Tôi đã để lại tất cả các tệp khác và mysql vẫn có thể bắt đầu.

CẬP NHẬT: hãy chắc chắn vô hiệu hóa innodb_force_recovery = 1khi mysql hoạt động trở lại, nếu không bạn sẽ gặp lỗi khi bạn cố gắng sửa đổi cơ sở dữ liệu và bảng.

Sau đó, tôi đã tạo lại cơ sở dữ liệu với Sequel Pro, nhập lại dữ liệu của mình và có thể tiếp tục mà không phải vứt bỏ tất cả các cơ sở dữ liệu khỏi các dự án khác của tôi.

Đi về phía trước, tôi phải giả định rằng bất kỳ cơ sở dữ liệu mysql nào cũng có thể bị hỏng và cố gắng giữ các bản sao lưu hàng ngày và để tập lệnh giải trí cơ sở dữ liệu được ghi lại hoặc mã hóa vào các công cụ tích hợp liên tục của tôi.