MariaDB频繁重启 InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < srv_page_size – 100

最近有个客户的MySQL数据库(MariaDB 10.6.20)总是频繁的重启,查看mariadb-error.log中显示“InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < srv_page_size – 100”, 简单记录该问题。

OS message log

Nov 17 21:14:03 anbob-com dhclient[2732888]: Packet received, but nothing done with it.
Nov 17 21:14:53 anbob-com systemd[1]: Started Process Core Dump (PID 3012150/UID 0).
Nov 17 21:14:53 anbob-com systemd-coredump[3012151]: Removed old coredump core.mariadbd.1108.14d93a26e35d4c6891693c1254a80b19.2427054.1763278079000000.lz4.
Nov 17 21:14:56 anbob-com systemd[1]: mariadb.service: Main process exited, code=killed, status=6/ABRT
Nov 17 21:14:56 anbob-com systemd[1]: mariadb.service: Failed with result 'signal'.
Nov 17 21:14:57 anbob-com systemd-coredump[3012151]: Process 3008742 (mariadbd) of user 1108 dumped core.#012#012Stack trace of thread 3012038:#012
#0  0x00007f9ca4d6f70f raise (libc.so.6)#012
#1  0x00007f9ca4d59bee abort (libc.so.6)#012#2  0x000055f5522beeb9 _Z23ut_dbg_assertion_failedPKcS0_j (mariadbd)#012
#3  0x000055f5522bea70 _ZL22trx_undo_header_createP11buf_block_tmP5mtr_t.cold.63 (mariadbd)#012
#4  0x000055f552a55cb7 _ZL21trx_undo_reuse_cachedP5trx_tP10trx_rseg_tPP10trx_undo_tP5mtr_tP7dberr_t (mariadbd)#012
#5  0x000055f552a59543 _Z19trx_undo_assign_lowILb0EEP11buf_block_tP5trx_tP10trx_rseg_tPP10trx_undo_tP5mtr_tP7dberr_t (mariadbd)#012
#6  0x000055f552a3b534 _Z29trx_undo_report_row_operationP9que_thr_tP12dict_index_tPK8dtuple_tPK5upd_tmPKhPKtPm (mariadbd)#012
#7  0x000055f552a70421 _ZL25btr_cur_ins_lock_and_undomP9btr_cur_tP8dtuple_tP9que_thr_tP5mtr_tPb (mariadbd)#012
#8  0x000055f552a736d7 _Z25btr_cur_optimistic_insertmP9btr_cur_tPPtPP16mem_block_info_tP8dtuple_tPPhPP9big_rec_tmP9que_thr_tP5mtr_t (mariadbd)#012
#9  0x000055f5529e801f _Z29row_ins_clust_index_entry_lowm14btr_latch_modeP12dict_index_tmP8dtuple_tmP9que_thr_t (mariadbd)#012
#10 0x000055f5529ece24 _Z25row_ins_clust_index_entryP12dict_index_tP8dtuple_tP9que_thr_tm (mariadbd)#012
#11 0x000055f5529ed736 _Z12row_ins_stepP9que_thr_t (mariadbd)#012
#12 0x000055f5529fdc58 _Z20row_insert_for_mysqlPKhP14row_prebuilt_t10ins_mode_t (mariadbd)#012
#13 0x000055f55295126f _ZN11ha_innobase9write_rowEPKh (mariadbd)#012
#14 0x000055f55265ca2f _ZN7handler12ha_write_rowEPKh (mariadbd)#012
#15 0x000055f5523c8dbd _Z12write_recordP3THDP5TABLEP12st_copy_infoP13select_result (mariadbd)#012
#16 0x000055f5523cf819 _Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesbP13select_result (mariadbd)#012#
...

mariadb-error.log

2025-11-17 21:14:14 127 [Warning] IP address '2409:8028:5af0:bb03::e:15' could not be resolved: Name or service not known
2025-11-17 21:14:51 0x7f8c59149700  InnoDB: Assertion failure in file /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.6.20/storage/innobase/trx/trx0undo.cc line 537
InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < srv_page_size - 100
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mariadbd startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
InnoDB: about forcing recovery.
251117 21:14:51 [ERROR] mysqld got signal 6 ;
Sorry, we probably made a mistake, and this is a bug.

Your assistance in bug reporting will enable us to fix this for the next release.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs

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.

Server version: 10.6.20-MariaDB-log source revision: f00711bba2cd383825d0be1867f7d7d7f641c9e4
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=77
max_threads=2002
thread_count=77
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4540262 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f8b00000c58
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 = 0x7f8c5914a000 thread_stack 0x49000
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x55f552b9180e]
/usr/sbin/mariadbd(handle_fatal_signal+0x485)[0x55f55264d5e5]
sigaction.c:0(__restore_rt)[0x7f9ca5c3fdd0]
/lib64/libc.so.6(gsignal+0x10f)[0x7f9ca4d6f70f]
/lib64/libc.so.6(abort+0x127)[0x7f9ca4d59b25]
/usr/sbin/mariadbd(+0x683eb9)[0x55f5522beeb9]
...
/usr/sbin/mariadbd(_ZN7handler12ha_write_rowEPKh+0x1cf)[0x55f55265ca2f]
/usr/sbin/mariadbd(_Z12write_recordP3THDP5TABLEP12st_copy_infoP13select_result+0x1dd)[0x55f5523c8dbd]
/usr/sbin/mariadbd(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesbP13select_result+0xd49)[0x55f5523cf819]
/usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0x2ce9)[0x55f55240be36]
/usr/sbin/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x275)[0x55f5523f951a]
/usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x1708)[0x55f55240670d]
..

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f8b00010b20): INSERT INTO log_table_xxx  ( log_id,user_id) values (xxxx,xxxx);

trx0undo Transaction undo log memory object; this is protected by the undo_mutex in the corresponding transaction object.

多个表上的DML都会触发crash,判断是因为undo段损坏,需要逻辑导出重建数据库.

启动数据库,不做任何DML,dump出sql,重建数据库即可。

如果 MySQL 无法正常启动,尝试以 InnoDB 恢复模式启动 MySQL。这可以通过在启动命令中添加 –innodb_force_recovery 选项来实现。

innodb_force_recovery 是 InnoDB 存储引擎的一个紧急恢复参数,用于在数据库异常崩溃后无法正常启动时,强制启动 InnoDB 以挽救数据。通常是从低向高逐渐增加。重启生效,级别4及以上时,数据可能不一致

innodb_force_recovery = level

各级别含义

级别功能风险程度
0正常模式,不强制恢复无风险
1忽略损坏的页低风险
2不运行主线程低风险
3不执行回滚操作中等风险
4不执行插入缓冲区合并操作中等风险
5不查看undo日志高风险
6不执行前滚操作最高风险
限制行为
在强制恢复模式下:
级别≥3:INSERTUPDATEDELETE 被禁止
级别≥4:某些后台操作被禁用
级别≥5:不读取undo日志,可能看到历史数据
级别6:不执行崩溃恢复的前滚阶段

注意: 生产操作有风险,如果寻求帮助,可联系www.anbob.com首页联系方式。

Leave a Comment