Details
Description
For reproducing initially, do not add galera_cluster.inc or other Galera-related configuration, just run the test as is, only with --mysqld=--wsrep-provider=<path to a galera library> on the command line.
I guess it may be related to the status "has not yet prepared node for application use", either permanent or temporary, and if so, configuring the cluster properly from the start will make it go away. Once the actual problem is figured out, a test case can be added to test files which handle such a state.
SET GLOBAL wsrep_on=ON; |
REPAIR TABLE performance_schema.setup_objects; |
10.5 fdb6db6b47f1825eabffde76c29d9b94545f1ef4 |
2024-11-29 12:47:19 4 [ERROR] WSREP: Unknown writeset version: -1
|
241129 12:47:19 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007f0fbfc45472 in __GI_abort () at ./stdlib/abort.c:79
|
#8 0x00007f0fb5652b6b in galera::WriteSetNG::Header::size (ver=ver@entry=4294967295) at ./galera/src/write_set_ng.hpp:171
|
#9 0x00007f0fb56549cb in galera::WriteSetNG::Header::Header (ver=4294967295, this=0x6250000f0218) at ./galera/src/write_set_ng.hpp:178
|
#10 galera::WriteSetOut::WriteSetOut (max_size=2147483647, uver=galera::DataSet::VER1, dver=galera::DataSet::VER1, ver=4294967295, rsv=gu::RecordSet::VER2, flags=0, reserved_size=5384, reserved=0x6250000f0bf8 '\276' <repeats 200 times>..., kver=galera::KeySet::FLAT8, id=18446744073709551615, dir_name="/mnt8t/bld/10.5-asan/mysql-test/var/mysqld.1/data/", this=0x6250000f0218) at ./galera/src/write_set_ng.hpp:513
|
#11 galera::TrxHandleMaster::init_write_set_out (this=0x6250000f0100) at ./galera/src/trx_handle.hpp:1067
|
#12 galera::TrxHandleMaster::write_set_out (this=this@entry=0x6250000f0100) at ./galera/src/trx_handle.hpp:1013
|
#13 0x00007f0fb564e249 in galera::TrxHandleMaster::set_flags (flags=69, this=0x6250000f0100) at ./galera/src/trx_handle.hpp:886
|
#14 galera_to_execute_start (gh=<optimized out>, conn_id=4, keys=0x602000034db0, keys_num=1, data=0x7f0fb6717070, count=1, flags=65, meta=0x7f0fb67171f8) at ./galera/src/wsrep_provider.cpp:1187
|
#15 0x000055d9fb6fb3f9 in wsrep::wsrep_provider_v26::enter_toi (this=0x606000047840, client_id=..., keys=std::__debug::vector of length 1, capacity 1 = {...}, buffer=..., ws_meta=..., flags=3) at /data/bld/10.5-asan/wsrep-lib/src/wsrep_provider_v26.cpp:1023
|
#16 0x000055d9fb67863b in wsrep::client_state::poll_enter_toi (this=0x62b00006f758, lock=..., keys=std::__debug::vector of length 1, capacity 1 = {...}, buffer=..., meta=..., flags=3, wait_until=..., timed_out=@0x7f0fb6717920: false) at /data/bld/10.5-asan/wsrep-lib/src/client_state.cpp:581
|
#17 0x000055d9fb6791d3 in wsrep::client_state::enter_toi_local (this=0x62b00006f758, keys=std::__debug::vector of length 1, capacity 1 = {...}, buffer=..., wait_until=...) at /data/bld/10.5-asan/wsrep-lib/src/client_state.cpp:633
|
#18 0x000055d9fa872db4 in wsrep_TOI_begin (thd=0x62b000069218, db=0x0, table=0x0, table_list=0x62b000038380, alter_info=0x0, fk_tables=0x0, create_info=0x0) at /data/bld/10.5-asan/sql/wsrep_mysqld.cc:2385
|
#19 0x000055d9fa874878 in wsrep_to_isolation_begin (thd=0x62b000069218, db_=0x0, table_=0x0, table_list=0x62b000038380, alter_info=0x0, fk_tables=0x0, create_info=0x0) at /data/bld/10.5-asan/sql/wsrep_mysqld.cc:2628
|
#20 0x000055d9f9afc236 in Sql_cmd_repair_table::execute (this=0x62b000038a88, thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_admin.cc:1543
|
#21 0x000055d9f9681d86 in mysql_execute_command (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_parse.cc:6179
|
#22 0x000055d9f968f153 in mysql_parse (thd=0x62b000069218, rawbuf=0x62b000038238 "REPAIR TABLE performance_schema.setup_objects", length=45, parser_state=0x7f0fb6718c70, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:8237
|
#23 0x000055d9f968de83 in wsrep_mysql_parse (thd=0x62b000069218, rawbuf=0x62b000038238 "REPAIR TABLE performance_schema.setup_objects", length=45, parser_state=0x7f0fb6718c70, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:8037
|
#24 0x000055d9f96642c8 in dispatch_command (command=COM_QUERY, thd=0x62b000069218, packet=0x629000235219 "REPAIR TABLE performance_schema.setup_objects", packet_length=45, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:1877
|
#25 0x000055d9f9660dcc in do_command (thd=0x62b000069218) at /data/bld/10.5-asan/sql/sql_parse.cc:1375
|
#26 0x000055d9f9abaaf5 in do_handle_one_connection (connect=0x608000002ab8, put_in_cache=true) at /data/bld/10.5-asan/sql/sql_connect.cc:1386
|
#27 0x000055d9f9aba65b in handle_one_connection (arg=0x608000002a38) at /data/bld/10.5-asan/sql/sql_connect.cc:1298
|
#28 0x000055d9fa71963a in pfs_spawn_thread (arg=0x615000006c18) at /data/bld/10.5-asan/storage/perfschema/pfs.cc:2201
|
#29 0x00007f0fbfca8044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#30 0x00007f0fbfd2861c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
See also MDEV-31377. I'm not sure whether it's the same scenario, but it may be the same problem.
Attachments
Issue Links
- relates to
-
MDEV-31377 Restarting replication slave in Galera cluster crashes repeatedly
- Open