WSREP_SST: [INFO] rsync SST completed on donor (20231031 11:22:25.919)

2023-10-31 11:22:25 0 [Note] WSREP: Donor monitor thread ended with total time 2 sec

2023-10-31 11:22:28 0 [Note] WSREP: async IST sender served

2023-10-31 11:22:28 0 [Note] WSREP: 2.0 (panda): State transfer from 0.0 (panda) complete.

2023-10-31 11:22:28 0 [Note] WSREP: Member 2.0 (panda) synced with group.

2023-10-31 11:22:30 18 [Note] Master connection name: ''  Master_info_file: 'master.info'  Relay_info_file: 'relay-log.info'

2023-10-31 11:22:30 18 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='', master_port='3306', master_log_file='', master_log_pos='4'. New state master_host='127.0.0.1', master_port='16000', master_log_file='', master_log_pos='4'.

2023-10-31 11:22:30 18 [Note] Previous Using_Gtid=No. New Using_Gtid=Current_Pos

2023-10-31 11:22:30 19 [Note] Slave I/O thread: Start asynchronous replication to master 'root@127.0.0.1:16000' in log '' at position 4

2023-10-31 11:22:30 20 [Note] Slave SQL thread initialized, starting replication in log 'FIRST' at position 4, relay log './mysqld-relay-bin.000001' position: 4; GTID position ''

2023-10-31 11:22:30 19 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:16000',replication starts at GTID position ''

2023-10-31 11:22:30 20 [Note] WSREP: ready state reached

mysqld: /home/panda/mariadb-10.4/wsrep-lib/src/transaction.cpp:734: int wsrep::transaction::before_rollback(): Assertion `0' failed.

231031 11:22:33 [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.4.32-MariaDB-debug-log source revision: 12c5dec8cc31fc327a3eb66b1b2c20647a66ed77

key_buffer_size=1048576

read_buffer_size=131072

max_used_connections=1

max_threads=153

thread_count=11

It is possible that mysqld could use up to 

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 63663 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7fef8c000da0

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 = 0x7feff7687558 thread_stack 0x49000

mysys/stacktrace.c:174(my_print_stacktrace)[0x55ac176e8517]

sql/signal_handler.cc:235(handle_fatal_signal)[0x55ac16d9517d]

libc_sigaction.c:0(__restore_rt)[0x7ff01e21b520]

nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7ff01e26f9fc]

posix/raise.c:27(__GI_raise)[0x7ff01e21b476]

stdlib/abort.c:81(__GI_abort)[0x7ff01e2017f3]

intl/loadmsgcat.c:1177(_nl_load_domain)[0x7ff01e20171b]

/lib/x86_64-linux-gnu/libc.so.6(+0x39e96)[0x7ff01e212e96]

src/transaction.cpp:732(wsrep::transaction::before_rollback())[0x55ac178bfb7c]

src/client_state.cpp:412(wsrep::client_state::before_rollback())[0x55ac1789c803]

sql/wsrep_trans_observer.h:407(wsrep_before_rollback(THD*, bool))[0x55ac16d97aca]

sql/handler.cc:1945(ha_rollback_trans(THD*, bool))[0x55ac16d9cbb4]

sql/transaction.cc:497(trans_rollback_stmt(THD*))[0x55ac16be8e0f]

sql/sql_admin.cc:49(admin_recreate_table(THD*, TABLE_LIST*, Recreate_info*))[0x55ac16be185a]

sql/sql_admin.cc:1129(mysql_admin_table(THD*, TABLE_LIST*, st_ha_check_opt*, char const*, thr_lock_type, bool, bool, unsigned int, int (*)(THD*, TABLE_LIST*, st_ha_check_opt*), int (handler::*)(THD*, st_ha_check_opt*), int (*)(THD*, TABLE_LIST*, st_ha_check_opt*), bool))[0x55ac16be5302]

sql/sql_admin.cc:1485(Sql_cmd_optimize_table::execute(THD*))[0x55ac16be68d1]

sql/sql_parse.cc:6218(mysql_execute_command(THD*))[0x55ac16a365a3]

sql/sql_parse.cc:8013(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x55ac16a3bb2d]

sql/log_event.cc:5747(Query_log_event::do_apply_event(rpl_group_info*, char const*, unsigned int))[0x55ac16f06609]

sql/log_event.cc:5423(Query_log_event::do_apply_event(rpl_group_info*))[0x55ac16f05461]

sql/log_event.h:1492(Log_event::apply_event(rpl_group_info*))[0x55ac16922604]

sql/slave.cc:3820(apply_event_and_update_pos_apply(Log_event*, THD*, rpl_group_info*, int))[0x55ac1691372e]

sql/slave.cc:3982(apply_event_and_update_pos(Log_event*, THD*, rpl_group_info*))[0x55ac16913d71]

sql/slave.cc:4341(exec_relay_log_event(THD*, Relay_log_info*, rpl_group_info*))[0x55ac16914909]

sql/slave.cc:5541(handle_slave_sql)[0x55ac169188e6]

perfschema/pfs.cc:1871(pfs_spawn_thread)[0x55ac1713ac16]

nptl/pthread_create.c:442(start_thread)[0x7ff01e26dac3]

x86_64/clone3.S:83(__clone3)[0x7ff01e2ffa40]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0x7fef8c03466b): OPTIMIZE TABLE t1

Connection ID (thread ID): 20

Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on