![更新 WordPress 后出现 MySQL 错误/损坏](https://linux22.com/image/777502/%E6%9B%B4%E6%96%B0%20WordPress%20%E5%90%8E%E5%87%BA%E7%8E%B0%20MySQL%20%E9%94%99%E8%AF%AF%2F%E6%8D%9F%E5%9D%8F.png)
昨天我将我的 Wordpress 网站更新为最新版本的 WordPress (6.0),并将其他几个插件更新为最新版本。更新后一切似乎都运行正常,所以我禁用了维护页面。几个小时后,我的远程 MySQL 服务器(用于 WP 数据库)崩溃了,今天早上我的 Web 服务器 (Nginx) 无法连接到数据库。
我从备份中恢复了生产服务器,并将可能损坏的卷从 MySQL 服务器附加到新实例。MySQL 无法启动,我一直在查看日志,但它们远远超出了我的专业水平。
以下是日志的两个部分。第一部分描述了潜在的损坏?我在 CNF 文件中添加了 innodb_force_recovery = 6,这样 MySQL 就可以启动了,但我真的不知道这意味着什么。这是否意味着 100% 保证会损坏?如果是这样,我该如何找出原因/在哪里?
第二部分有一个缓冲池错误,这对我来说更容易理解。我在 CNF 文件中注释掉了 innodb_buffer_pool_size 设置,但这对 MySQL 启动没有影响,除非将 innodb_force_recovery 设置为 6。
我希望有人可以解释这些错误以及如何找出原因?
MySQL8.0.29 R6G.Large(2 核,16GB RAM)缓冲池:12000M
第 1 部分:
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/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:49:04 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0xfffc28000b20
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 = 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]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
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.
2022-05-25T18:49:04.565524Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authentication_policy instead.
2022-05-25T18:49:04.565544Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.29) starting as process 6679
2022-05-25T18:49:04.571539Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-05-25T18:49:05.807854Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-05-25T18:49:06.622221Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2022-05-25T18:49:06.625449Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
2022-05-25T18:49:07.251794Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2022-05-25T18:49:07.251829Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2022-05-25T18:49:07.272581Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2022-05-25T18:49:07.272631Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.29' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server - 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] Assertion failure: page0page.cc:502:ib::fatal triggered thread 281457662619536
第 2 部分:
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.
2022-05-26T12:27:29.518146Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authentication_policy instead.
2022-05-26T12:27:29.518165Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.29) starting as process 17135
2022-05-26T12:27:29.524074Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-05-26T13:20:40.613066Z 0 [Warning] [MY-010918] [Server] 'default_authentication_plugin' is deprecated and will be removed in a future release. Please use authentication_policy instead.
2022-05-26T13:20:40.613087Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.29) starting as process 1086
2022-05-26T13:20:41.866918Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-05-26T13:20:49.824464Z 0 [Warning] [MY-012681] [InnoDB] page_aligned_alloc mmap(137232384 bytes) failed; errno 12
2022-05-26T13:20:49.844869Z 0 [Warning] [MY-012681] [InnoDB] page_aligned_alloc mmap(137232384 bytes) failed; errno 12
2022-05-26T13:20:49.961232Z 1 [ERROR] [MY-012956] [InnoDB] Cannot allocate memory for the buffer pool
2022-05-26T13:20:49.961279Z 1 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Generic error.
2022-05-26T13:20:49.962080Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2022-05-26T13:20:49.962240Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2022-05-26T13:20:49.962355Z 0 [ERROR] [MY-010119] [Server] Aborting
2022-05-26T13:20:49.966630Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.29) MySQL Community Server - GPL.
任何帮助都将非常有帮助。
更新:我在有故障的数据库上运行了 mysqlcheck,发现损坏。看起来原因是 WooCommerce?
以下是 mysqlcheck 返回的错误:
production.wp_wc_admin_note_actions
Warning : InnoDB: The B-tree of index PRIMARY is corrupted.
Warning : InnoDB: Index 'note_id' contains 1004 entries, should be 18446744073709551615.
error : Corrupt
杰克
答案1
这个问题MySQL 社区论坛中也有报道。
在首次报告后不久,其他几位 MySQL 8.0.29 用户做出了回应,称他们也遇到了类似的问题,通常与wc_admin_note_actions
Wordpress 插件 Woocommerce 的表有关。
最后,一位用户能够重现该问题和在 MySQL 错误跟踪器中报告了此问题。
不幸的是,无法查看该问题。根据我自己的经验,我可以说,这是因为 MySQL 团队将导致崩溃/数据损坏的问题视为安全问题,因此在其错误跟踪器中将其隐藏起来,不让公众看到。
话虽如此,另一位用户的最后一篇帖子确认 MySQL 团队已接受所报告的问题(因此他们能够重现它)。
据这位用户称,可以通过在mysqlcheck -Ao
升级到 MySQL 8.0.29 的系统上运行来防止此问题,但是,如果已经有损坏的表(并且由于它是静默损坏,您可能只有在访问它们时才会注意到),它将导致 MySQL 服务器崩溃,您可能必须使用innodb_force_recovery
或从备份中进行恢复。