Điểm:1

Lỗi MySQL / Tham nhũng sau khi cập nhật WordPress

lá cờ cn

Hôm qua tôi đã cập nhật trang web Wordpress của mình lên phiên bản WordPress mới nhất (6.0) và tôi đã cập nhật một số plugin khác lên phiên bản mới nhất của chúng.Sau khi cập nhật, mọi thứ dường như hoạt động tốt, vì vậy tôi đã tắt trang bảo trì của mình. Vài giờ sau, máy chủ MySQL từ xa của tôi (được sử dụng cho cơ sở dữ liệu WP) bị lỗi và sáng nay Máy chủ Web (Nginx) của tôi không thể kết nối với cơ sở dữ liệu.

Tôi đã khôi phục các máy chủ sản xuất của mình từ bản sao lưu và tôi đã đính kèm ổ đĩa có khả năng bị hỏng từ máy chủ MySQL vào một phiên bản mới. MySQL sẽ không khởi động và tôi đã xem xét nhật ký, nhưng chúng vượt xa trình độ chuyên môn của tôi.

Dưới đây là hai phần của nhật ký. Đầu tiên mô tả tham nhũng tiềm năng? Tôi đã thêm innodb_force_recovery = 6 vào tệp CNF của mình và điều đó cho phép MySQL khởi động, nhưng tôi thực sự không biết điều này có nghĩa là gì. Điều đó có nghĩa là đảm bảo 100% có tham nhũng và nếu có thì làm cách nào để tìm ra nguyên nhân/ở đâu?

Phần thứ hai có lỗi vùng đệm, tôi dễ hiểu hơn một chút. Tôi đã nhận xét cài đặt innodb_buffer_pool_size trong tệp CNF của mình, nhưng điều đó không ảnh hưởng đến MySQL khi bắt đầu mà không có innodb_force_recovery được đặt thành 6.

Tôi hy vọng ai đó có thể giải thích các lỗi và có khả năng làm thế nào để tìm ra (các) nguyên nhân?

MySQL8.0.29 R6G.Large (2 nhân, ram 16gb) Vùng đệm: 12000M

Phần 1:

InnoDB: Chúng tôi cố tình tạo bẫy bộ nhớ.
InnoDB: Gửi báo cáo lỗi chi tiết tới http://bugs.mysql.com.
InnoDB: Nếu bạn gặp sự cố hoặc lỗi 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/8.0/en/forcing-innodb-recovery.html
InnoDB: về việc buộc phục hồi.
18:49:04 UTC - mysqld có tín hiệu 6 ;
Nhiều khả năng là bạn đã gặp phải lỗi, nhưng lỗi này cũng có thể do phần cứng bị trục trặc.
Con trỏ luồng: 0xfffc28000b20
Đang cố 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 đó, điều gì đó đã xảy ra
sai kinh khủng...
stack_bottom = fffc488565f0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x44) [0x1d0e2a4]
/usr/sbin/mysqld(print_fatal_signal(int)+0x28c) [0xe3278c]
/usr/sbin/mysqld(my_server_abort()+0xa0) [0xe32920]
/usr/sbin/mysqld(my_abort()+0x14) [0x1d08244]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x290) [0x1f79ba0]
/usr/sbin/mysqld() [0x1f7c42c]
/usr/sbin/mysqld(page_copy_rec_list_end_no_locks(buf_block_t*, buf_block_t*, unsigned char*, dict_index_t*, mtr_t*)+0x2dc) [0x1ec1dec]
/usr/sbin/mysqld(page_copy_rec_list_end(buf_block_t*, buf_block_t*, unsigned char*, dict_index_t*, mtr_t*)+0x300) [0x1ec2270]
/usr/sbin/mysqld(btr_compress(btr_cur_t*, bool, mtr_t*)+0x624) [0x1fa53f4]
/usr/sbin/mysqld(btr_cur_pessimistic_delete(dberr_t*, bool, btr_cur_t*, unsigned int, bool, unsigned long, unsigned long, unsigned long, mtr_t*, btr_pcur_t*, purge_node_t*)+0x1cc) [0x1fb130c]
/usr/sbin/mysqld() [0x1f02bf8]
/usr/sbin/mysqld(row_purge_step(que_thr_t*)+0x4f4) [0x1f05364]
/usr/sbin/mysqld(que_run_threads(que_thr_t*)+0x578) [0x1ece5e8]
/usr/sbin/mysqld(srv_worker_thread()+0x21c) [0x1f3184c]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (*)()> > >::_M_run()+0xd4) [0x1e85774]
/usr/sbin/mysqld() [0x244623c]
/lib64/libpthread.so.0(+0x722c) [0xffffab1ec22c]
/lib64/libc.so.6(+0xd2e5c) [0xffffaaa99e5c]

Cố gắng để có được một số biến.
Một số con trỏ có thể không hợp lệ và khiến quá trình kết xuất bị hủy bỏ.
Truy vấn (0): ID kết nối (ID luồng): 0
Trạng thái: NOT_KILLED

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 nguyên nhân gây ra sự cố.
2022-05-25T18:49:04.565524Z 0 [Cảnh báo] [MY-010918] [Máy ​​chủ] 'default_authentication_plugin' không được dùng nữa và sẽ bị xóa trong bản phát hành trong tương lai. Vui lòng sử dụng authentication_policy để thay thế.
2022-05-25T18:49:04.565544Z 0 [Hệ thống] [MY-010116] [Máy ​​chủ] /usr/sbin/mysqld (mysqld 8.0.29) bắt đầu dưới dạng quy trình 6679
2022-05-25T18:49:04.571539Z 1 [Hệ thống] [MY-013576] [InnoDB] Khởi tạo InnoDB đã bắt đầu.
2022-05-25T18:49:05.807854Z 1 [Hệ thống] [MY-013577] [InnoDB] Quá trình khởi tạo InnoDB đã kết thúc.
2022-05-25T18:49:06.622221Z 0 [Hệ thống] [MY-010229] [Máy ​​chủ] Bắt đầu khôi phục sự cố XA...
2022-05-25T18:49:06.625449Z 0 [Hệ thống] [MY-010232] [Máy ​​chủ] Quá trình khôi phục sự cố XA đã hoàn tất.
2022-05-25T18:49:07.251794Z 0 [Cảnh báo] [MY-010068] [Máy ​​chủ] Chứng chỉ CA ca.pem tự ký.
2022-05-25T18:49:07.251829Z 0 [Hệ thống] [MY-013602] [Máy ​​chủ] Kênh mysql_main được định cấu hình để hỗ trợ TLS. Kết nối được mã hóa hiện được hỗ trợ cho kênh này.
2022-05-25T18:49:07.272581Z 0 [Hệ thống] [MY-011323] [Máy ​​chủ] Plugin X sẵn sàng cho các kết nối. Địa chỉ liên kết: '::' cổng: 33060, ổ cắm: /var/run/mysqld/mysqlx.sock
2022-05-25T18:49:07.272631Z 0 [Hệ thống] [MY-010931] [Máy ​​chủ] /usr/sbin/mysqld: sẵn sàng kết nối. Phiên bản: '8.0.29' ổ cắm: '/var/lib/mysql/mysql.sock' cổng: 3306 Máy chủ Cộng đồng MySQL - GPL.
2022-05-25T18:49:07.347411Z 0 [ERROR] [MY-012687] [InnoDB] [FATAL] Rec offset 99, cur1 offset 4038, cur2 offset 16004
2022-05-25T18:49:07.347449Z 0 [ERROR] [MY-013183] [InnoDB] Lỗi xác nhận: page0page.cc:502:ib::chuỗi kích hoạt gây tử vong 281457662619536

Phần 2:

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 nguyên nhân gây ra sự cố.
2022-05-26T12:27:29.518146Z 0 [Cảnh báo] [MY-010918] [Máy ​​chủ] 'default_authentication_plugin' không được dùng nữa và sẽ bị xóa trong bản phát hành trong tương lai. Vui lòng sử dụng authentication_policy để thay thế.
2022-05-26T12:27:29.518165Z 0 [Hệ thống] [MY-010116] [Máy ​​chủ] /usr/sbin/mysqld (mysqld 8.0.29) bắt đầu từ quy trình 17135
2022-05-26T12:27:29.524074Z 1 [Hệ thống] [MY-013576] [InnoDB] Khởi tạo InnoDB đã bắt đầu.
2022-05-26T13:20:40.613066Z 0 [Cảnh báo] [MY-010918] [Máy ​​chủ] 'default_authentication_plugin' không được dùng nữa và sẽ bị xóa trong bản phát hành trong tương lai. Vui lòng sử dụng authentication_policy để thay thế.
2022-05-26T13:20:40.613087Z 0 [Hệ thống] [MY-010116] [Máy ​​chủ] /usr/sbin/mysqld (mysqld 8.0.29) bắt đầu dưới dạng quy trình 1086
2022-05-26T13:20:41.866918Z 1 [Hệ thống] [MY-013576] [InnoDB] Khởi tạo InnoDB đã bắt đầu.
2022-05-26T13:20:49.824464Z 0 [Cảnh báo] [MY-012681] [InnoDB] page_aligned_alloc mmap(137232384 byte) không thành công; lỗi 12
2022-05-26T13:20:49.844869Z 0 [Cảnh báo] [MY-012681] [InnoDB] page_aligned_alloc mmap(137232384 byte) không thành công; lỗi 12
2022-05-26T13:20:49.961232Z 1 [ERROR] [MY-012956] [InnoDB] Không thể phân bổ bộ nhớ cho vùng đệm
2022-05-26T13:20:49.961279Z 1 [ERROR] [MY-012930] [InnoDB] Quá trình khởi tạo plugin bị hủy bỏ do lỗi Lỗi chung.
2022-05-26T13:20:49.962080Z 1 [ERROR] [MY-010334] [Server] Không thể khởi tạo DD Storage Engine
2022-05-26T13:20:49.962240Z 0 [ERROR] [MY-010020] [Server] Quá trình khởi tạo Từ điển dữ liệu không thành công.
2022-05-26T13:20:49.962355Z 0 [ERROR] [MY-010119] [Server] Đang hủy bỏ
2022-05-26T13:20:49.966630Z 0 [Hệ thống] [MY-010910] [Máy ​​chủ] /usr/sbin/mysqld: Tắt hoàn tất (mysqld 8.0.29) Máy chủ cộng đồng MySQL - GPL.

Bất kỳ sự trợ giúp nào đều sẽ là tuyệt vời.

Cập nhật: Tôi đã chạy mysqlcheck trên cơ sở dữ liệu bị lỗi của mình và nó phát hiện ra lỗi. Có vẻ như nguyên nhân là do WooC Commerce?

Đây là lỗi mysqlcheck trả về:

sản xuất.wp_wc_admin_note_actions
Cảnh báo: InnoDB: Cây B của chỉ mục CHÍNH bị hỏng.
Cảnh báo: InnoDB: Chỉ mục 'note_id' chứa 1004 mục, phải là 18446744073709551615.
lỗi: Hỏng

Jack

lá cờ ua
Gửi lỗi tại bug.mysql.com - Tôi không nghĩ rằng WP có lỗi _directly_. Có bất cứ điều gì khác xảy ra cùng một lúc? Chẳng hạn như mất điện, hỏng đĩa, v.v?
lá cờ cn
Này Rick, Không phải tôi đã tìm thấy. Mọi thứ khác có vẻ ổn. Sẽ không có lỗi nào ảnh hưởng đến bản sao lưu của tôi, vốn không có bất kỳ sự cố nào? Ổ đĩa bị ảnh hưởng đã chạy trên một phiên bản riêng trong chế độ khôi phục 6 trong 24 giờ và không gặp thêm bất kỳ sự cố nào. Có cách nào để tìm hiểu xem có bảng bị hỏng hay nguyên nhân không?
lá cờ ua
"Trên mức lương của tôi"
lá cờ cn
Của tôi cũng vậy :) , hy vọng một thành viên khác sẽ có một số ý tưởng. Cảm ơn
lá cờ cn
@RickJames, có vẻ như bản cập nhật WooC Commerce đã gây ra sự cố. Tôi đã tìm ra cách sử dụng mysqlcheck và nó đã tìm thấy tham nhũng trong wp_wc_admin_note_actions, xem ở trên, tôi đã cập nhật bài đăng của mình.
lá cờ ua
Có phải bảng Engine=MyISAM không? Điều đó có vấn đề tham nhũng. Chuyển sang InnoDB.
lá cờ cn
Đó là innoDB, tôi chưa bao giờ sử dụng MyISAM. Tôi đã liên hệ với bộ phận hỗ trợ của WooC Commerce và họ đang điều tra.
Wilson Hauck avatar
lá cờ jp
Jack, Bạn đã bước qua innodb_force_recovery=1 rồi 2 rồi 3 hay đi thẳng đến 6? Bước là phương pháp được lập thành văn bản cho dữ liệu có thể khôi phục được nhiều nhất với mức độ nguy hiểm ít nhất.
lá cờ cn
Wilson, không, tôi chỉ đọc tài liệu đó sau đó. Tôi có đầy đủ các bản sao lưu trước khi bị hỏng và tôi có một bản sao lưu của máy chủ bị hỏng trước khi bắt buộc khôi phục. Tôi đã khôi phục máy chủ bị hỏng kể từ khi sao lưu và khôi phục 1 không khởi động lại, nhưng 2 thì có. Tôi vẫn chưa thể thu hẹp nguyên nhân. WooC Commerce cho biết đó không phải là họ và không ai khác đã báo cáo sự cố. Bất kỳ ý tưởng về làm thế nào để tìm ra nguyên nhân?
lá cờ jp
Chúng tôi đang sseing chính xác cùng một vấn đề. Chúng tôi đang chạy khoảng 300 máy chủ MySQL 8.0.29. Trong 2 tuần rưỡi qua, chúng tôi đã thấy sự cố này trên ít nhất chín máy chủ MySQL. Nó hầu như luôn liên quan đến bảng bạn đã đề cập: wp_wc_admin_note_actions. Điều đó đang được nói, chúng tôi cũng đã thấy nó trên các bảng khác. Tôi đã tạo một chủ đề trong các diễn đàn MySQL cho vấn đề này: https://forums.mysql.com/read.php?22,704532,704532#msg-704532 Thật không may, tôi không thể tạo lại sự cố này, mặc dù đã thử rất nhiều , nó dường như chỉ xảy ra ngẫu nhiên, cho đến nay.
lá cờ cn
@user40974 , rất thú vị! Bạn chỉ gặp sự cố kể từ khi nâng cấp WordPress hoặc WooC Commerce phải không? Tôi đang lên kế hoạch sao chép môi trường sản xuất của mình và cập nhật từng cái một, với 24 giờ giữa mỗi lần cập nhật và kiểm tra cơ sở dữ liệu xem có bị hỏng không trước khi cập nhật lần tiếp theo. WooC Commerce dường như nghĩ rằng đó không phải là họ. Tôi không nghĩ đó là MySQL, vì các cơ sở dữ liệu MySQL khác của tôi chạy cùng phiên bản nhưng không được kết nối với WordPress, v.v. không gặp sự cố.
lá cờ jp
@JackJohnstone53 Thật không may, tôi chỉ có thể nhìn thấy điều này từ góc độ bên ngoài, làm việc với tư cách là quản trị viên hệ thống, vì vậy tôi thường chỉ nhận thấy khi đã quá muộn và tôi không biết chính xác khách hàng của mình đã làm gì trước đó. Có vẻ như nó thực sự thường được kết nối với bản nâng cấp của Wooc Commerce. Nhưng như đã nói, tôi cũng đã thấy điều này xảy ra với các bảng plugin wordpress khác, vì vậy tôi đoán đó là lỗi của MySQL. Một plugin không thể làm hỏng cơ sở dữ liệu InnoDB, bất kể dữ liệu mà nó cung cấp/sửa đổi kỳ lạ đến mức nào. Nó cũng bắt đầu sau khi nâng cấp 8.0.29.
lá cờ jp
Một bảng khác mà chúng tôi có hai trường hợp này được gọi là "spbc_scan_results". Điều đó dường như có liên quan đến plugin wordpress này: https://de.wordpress.org/plugins/security-malware-firewall/
lá cờ cn
@ user40974, tôi luôn nghĩ rằng plugin có thể làm hỏng cơ sở dữ liệu, nhưng điều đó vượt quá trình độ năng lực của tôi. Tôi sẽ liên hệ với bộ phận hỗ trợ WooC Commerce và gửi cho họ các liên kết cho chủ đề và bài đăng trên diễn đàn MySQL của bạn. Tôi sẽ cập nhật chủ đề nếu tôi tìm thấy bất cứ điều gì. Cảm ơn!

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.