Server Version: 8.0.32-25 断言失败 导致服务器 crash
2024-07-12T15:08:52.663024+08:00 401336 Assertion failure: row0pread.cc:1350:is_queue_empty() thread 140160146601728InnoDB: 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/ ... nnodb-recovery.html
InnoDB: about forcing recovery.
2024-07-12T07:08:52Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID=029072ec4fefcea616d05fa2631b046215e2e6dc
Build ID: 029072ec4fefcea616d05fa2631b046215e2e6dc
Server Version: 8.0.32-25 GreatSQL, Release 25, Revision 79f57097e3f
Thread pointer: 0x7f7994a00070
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 = 7f7993bfd1f0 thread_stack 0x80000
/usr/local/GreatSQL/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d)
/usr/local/GreatSQL/bin/mysqld(print_fatal_signal(int)+0x3cf)
/usr/local/GreatSQL/bin/mysqld(my_server_abort()+0x7e)
/usr/local/GreatSQL/bin/mysqld(my_abort()+0xa)
/usr/local/GreatSQL/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x31f)
/usr/local/GreatSQL/bin/mysqld(Parallel_reader::dispatch_ctx(row_prebuilt_t*)+0x405)
/usr/local/GreatSQL/bin/mysqld(ha_innobase::pq_worker_scan_next(void*, unsigned char*)+0x12b)
/usr/local/GreatSQL/bin/mysqld(handler::ha_pq_next(unsigned char*, void*)+0x270)
/usr/local/GreatSQL/bin/mysqld(PQblockScanIterator::Read()+0x25)
/usr/local/GreatSQL/bin/mysqld(FilterIterator::Read()+0x14)
/usr/local/GreatSQL/bin/mysqld(Query_expression::ExecuteIteratorQuery(THD*)+0xa72)
/usr/local/GreatSQL/bin/mysqld(pq_worker_exec(void*)+0x90)
/usr/local/GreatSQL/bin/mysqld()
/usr/lib64/libpthread.so.0(+0x7ea5)
/usr/lib64/libc.so.6(clone+0x6d)
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f7b23ab2830): SELECT id,uid,openid,unionid,session_key,phone_number,pure_phone_number,country_code,nick_name,gender,language,country,province,city,avatar_url,status,createTime,updateTimeFROM edu_wechat_user_infoWHEREopenid = 'o7OWs647O_4MWjnIlF4Ig9CLcFBA'
Connection ID (thread ID): 401336
Status: NOT_KILLED
Please help us make Percona Server better by reporting any
bugs at https://bugs.percona.com/
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
已知的老问题了哈,请关闭InnoDB PQ特性,参见:https://greatsql.cn/docs/8.0.32-25/11-faq/5-faq-others.html#_15-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%9C%A8greatsql%E4%B8%AD%E8%BF%90%E8%A1%8C%E4%B8%80%E4%BA%9Bsql%E5%90%8E%E6%95%B0%E6%8D%AE%E5%BA%93crash%E4%BA%86-%E8%AF%A5%E6%80%8E%E4%B9%88%E5%8A%9E yejr 发表于 2024-7-12 16:08
已知的老问题了哈,请关闭InnoDB PQ特性,参见:https://greatsql.cn/docs/8.0.32-25/11-faq/5-faq-others. ...
嗯 确实是开了PQ特性 mabai 发表于 2024-7-12 16:45
嗯 确实是开了PQ特性
如果这样,PQ特性不要轻易使用。 reddey 发表于 2024-7-12 17:04
如果这样,PQ特性不要轻易使用。
是的,较早前我已经把 my.cnf 的配置默认关了
页:
[1]