[MDEV-30185] Crash MariaDB in cascade Created: 2022-12-09  Updated: 2022-12-27

Status: Open
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.7.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Aurélien LEQUOY Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Debian 11



 Description   

2022-10-03 07:21:03 0x7effa0ff9700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221003  7:21:03 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=344
max_threads=1002
thread_count=380
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x5594a4a06298
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 = 0x7effa0ff8c98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x5594a294e93e]
??:0(handle_fatal_signal)[0x5594a2438a55]
sigaction.c:0(__restore_rt)[0x7f0637091140]
linux/raise.c:51(__GI_raise)[0x7f0636bc8ce1]
stdlib/abort.c:81(__GI_abort)[0x7f0636bb2537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x5594a2083aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x5594a2095406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x5594a2887f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x5594a2888198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x5594a288a3af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x5594a2095f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x5594a2086acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a283d051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a27cc200]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a27ccf7e]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a27cd90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a2792982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x5594a27ea778]
??:0(tpool::task_group::execute(tpool::task*))[0x5594a28e6f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x5594a28e616f]
??:0(std::error_code::default_error_condition() const)[0x7f0636f79ed0]
nptl/pthread_create.c:478(start_thread)[0x7f0637085ea7]
x86_64/clone.S:97(__GI___clone)[0x7f0636c8caef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-03  7:21:12 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-03  7:21:12 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-03  7:21:12 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-03  7:21:12 0 [Note] InnoDB: Using liburing
2022-10-03  7:21:12 0 [Note] InnoDB: Initializing buffer pool, total size = 25769803776, chunk size = 134217728
2022-10-03  7:21:12 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-03  7:21:12 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=930294293956,930344292131
2022-10-03  7:21:14 0 [Note] InnoDB: 4 transaction(s) which must be rolled back or cleaned up in total 4 row operations to undo
2022-10-03  7:21:14 0 [Note] InnoDB: Trx id counter is 1072912134
2022-10-03  7:21:14 0 [Note] InnoDB: Starting final batch to recover  75847 pages from redo log.
2022-10-03  7:21:19 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000268', position 474182899
2022-10-03  7:21:19 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-03  7:21:19 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-10-03  7:21:19 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-03  7:21:19 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-03  7:21:19 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-03  7:21:19 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-03  7:21:19 0 [Note] InnoDB: 10.7.4 started; log sequence number 930406073523; transaction id 1072912135
2022-10-03  7:21:19 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-03  7:21:19 0 [Note] Plugin 'FEEDBACK' is disabled.
221003  7:21:19 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221003  7:21:19 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-03  7:21:19 0 [Note] InnoDB: Rolled back recovered transaction 1072912103
2022-10-03  7:21:19 0 [Note] InnoDB: Rolled back recovered transaction 1072912053
2022-10-03  7:21:19 0 [Note] InnoDB: Rolled back recovered transaction 1072912113
2022-10-03  7:21:19 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-03  7:21:19 0 [Note] Starting table crash recovery...
2022-10-03  7:21:19 0 [Note] Crash table recovery finished.
2022-10-03  7:21:19 0 [Note] InnoDB: Rolled back recovered transaction 1072912133
2022-10-03  7:21:19 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-10-03  7:21:30 0 [Note] InnoDB: Buffer pool(s) load completed at 221003  7:21:30
2022-10-03  7:21:31 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-03  7:21:31 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-03  7:21:31 4 [Note] Started replication for 'profil6a10'
2022-10-03  7:21:31 4 [Note] Started replication for 'profil1a5'
2022-10-03  7:21:31 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-03  7:22:06 348 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000268, 474284257), using_gtid(0), gtid('')
2022-10-03  7:55:15 1738 [Note] Detected table cache mutex contention at instance 1: 37% waits. Additional table cache instance activated. Number of instances after activation: 2.
2022-10-03  8:15:27 2904 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000173, 449174905), using_gtid(0), gtid('')
2022-10-07 10:47:05 276002 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000396, 33209335), using_gtid(0), gtid('')
2022-10-07 10:50:22 276157 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000427, 333563107), using_gtid(0), gtid('')
2022-10-07 10:50:23 276156 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000396, 615380745), using_gtid(0), gtid('')
2022-10-07 13:33:25 283736 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000429, 759212192), using_gtid(0), gtid('')
 
 
---------------------------------
 
 
2022-10-09 21:06:02 0x7f2861e9c700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221009 21:06:02 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=619
max_threads=1002
thread_count=500
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x55e53574d138
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 = 0x7f2861e9bc98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55e53341a93e]
??:0(handle_fatal_signal)[0x55e532f04a55]
sigaction.c:0(__restore_rt)[0x7f2f93887140]
linux/raise.c:51(__GI_raise)[0x7f2f933bece1]
stdlib/abort.c:81(__GI_abort)[0x7f2f933a8537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e532b4faa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e532b61406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e533353f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e533354198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e5333563af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e532b61f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e532b52acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e533309051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e5332967e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e5332990a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e53329990b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e53325e982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e5332be5ca]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e5332b6aad]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e5332b6692]
??:0(tpool::task_group::execute(tpool::task*))[0x55e5333b2f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x55e5333b216f]
??:0(std::error_code::default_error_condition() const)[0x7f2f9376fed0]
nptl/pthread_create.c:478(start_thread)[0x7f2f9387bea7]
x86_64/clone.S:97(__GI___clone)[0x7f2f93482aef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-09 21:06:10 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-09 21:06:10 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-09 21:06:10 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-09 21:06:10 0 [Note] InnoDB: Using liburing
2022-10-09 21:06:10 0 [Note] InnoDB: Initializing buffer pool, total size = 25769803776, chunk size = 134217728
2022-10-09 21:06:10 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-09 21:06:10 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1057341796293,1057426003833
2022-10-09 21:06:23 0 [Note] InnoDB: 4 transaction(s) which must be rolled back or cleaned up in total 4 row operations to undo
2022-10-09 21:06:23 0 [Note] InnoDB: Trx id counter is 1607369955
2022-10-09 21:06:23 0 [Note] InnoDB: Starting final batch to recover  268962 pages from redo log.
2022-10-09 21:06:25 0 [Note] InnoDB: To recover: 223977 pages from log
2022-10-09 21:06:40 0 [Note] InnoDB: To recover: 50936 pages from log
2022-10-09 21:06:44 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000497', position 249405983
2022-10-09 21:06:44 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-09 21:06:44 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-10-09 21:06:44 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-09 21:06:44 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-09 21:06:44 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-09 21:06:44 0 [Note] InnoDB: Rolled back recovered transaction 1607369954
2022-10-09 21:06:44 0 [Note] InnoDB: Rolled back recovered transaction 1607369944
2022-10-09 21:06:44 0 [Note] InnoDB: Rolled back recovered transaction 1607369949
2022-10-09 21:06:44 0 [Note] InnoDB: Rolled back recovered transaction 1607369856
2022-10-09 21:06:44 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-10-09 21:06:44 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-09 21:06:44 0 [Note] InnoDB: 10.7.4 started; log sequence number 1058073888715; transaction id 1607369960
2022-10-09 21:06:44 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-09 21:06:44 0 [Note] Plugin 'FEEDBACK' is disabled.
221009 21:06:44 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221009 21:06:44 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-09 21:06:44 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-09 21:06:44 0 [Note] Starting table crash recovery...
2022-10-09 21:06:44 0 [Note] Crash table recovery finished.
2022-10-09 21:06:54 0 [Note] InnoDB: Buffer pool(s) load completed at 221009 21:06:54
2022-10-09 21:06:55 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-09 21:06:55 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-09 21:06:55 4 [Note] Started replication for 'profil6a10'
2022-10-09 21:06:55 4 [Note] Started replication for 'profil1a5'
2022-10-09 21:06:55 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-09 21:07:05 218 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000497, 249542224), using_gtid(0), gtid('')
2022-10-09 21:07:05 219 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000497, 249542224), using_gtid(0), gtid('')
2022-10-12  9:19:20 219724 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000570, 885691897), using_gtid(0), gtid('')
2022-10-13  8:01:25 0 [Note] InnoDB: Resizing buffer pool from 25769803776 to 21474836480 (unit=134217728).
2022-10-13  8:01:25 0 [Note] InnoDB: Disabling adaptive hash index.
2022-10-13  8:01:25 0 [Note] InnoDB: Withdrawing blocks to be shrunken.
2022-10-13  8:01:25 0 [Note] InnoDB: start to withdraw the last 259584 blocks
2022-10-13  8:01:25 302503 [Note] InnoDB: Requested to resize buffer pool. (new size: 21474836480 bytes)
2022-10-13  8:01:28 0 [Note] InnoDB: withdrawing blocks. (259333/259584)
2022-10-13  8:01:28 0 [Note] InnoDB: withdrew 0 blocks from free list. Tried to relocate 213250 pages (259333/259584)
2022-10-13  8:01:29 0 [Note] InnoDB: withdrawing blocks. (259584/259584)
2022-10-13  8:01:29 0 [Note] InnoDB: withdrew 0 blocks from free list. Tried to relocate 0 pages (259584/259584)
2022-10-13  8:01:29 0 [Note] InnoDB: withdrawn target: 259584 blocks
2022-10-13  8:01:29 0 [Note] InnoDB: Latching whole of buffer pool.
2022-10-13  8:01:29 0 [Note] InnoDB: buffer pool resizing with chunks 192 to 160.
2022-10-13  8:01:29 0 [Note] InnoDB: 32 chunks (259584 blocks) were freed.
2022-10-13  8:01:29 0 [Note] InnoDB: Completed to resize buffer pool from 25769803776 to 21474836480.
2022-10-13  8:01:29 0 [Note] InnoDB: Completed resizing buffer pool at 221013  8:01:29.
 
 
2022-10-15 01:49:02 0x7f459a7fc700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221015  1:49:02 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=374
max_threads=1002
thread_count=380
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x55d4f4b123d8
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 = 0x7f459a7fbc98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55d4f2f1b93e]
??:0(handle_fatal_signal)[0x55d4f2a05a55]
sigaction.c:0(__restore_rt)[0x7f4abd8d1140]
linux/raise.c:51(__GI_raise)[0x7f4abd408ce1]
stdlib/abort.c:81(__GI_abort)[0x7f4abd3f2537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55d4f2650aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55d4f2662406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55d4f2e54f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55d4f2e55198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55d4f2e573af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55d4f2662f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55d4f2653acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2e0a051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2d977e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2d9a0a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2d9a90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2d5f982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55d4f2db7778]
??:0(tpool::task_group::execute(tpool::task*))[0x55d4f2eb3f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x55d4f2eb316f]
??:0(std::error_code::default_error_condition() const)[0x7f4abd7b9ed0]
nptl/pthread_create.c:478(start_thread)[0x7f4abd8c5ea7]
x86_64/clone.S:97(__GI___clone)[0x7f4abd4ccaef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-15  1:49:09 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-15  1:49:09 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-15  1:49:09 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-15  1:49:09 0 [Note] InnoDB: Using liburing
2022-10-15  1:49:09 0 [Note] InnoDB: Initializing buffer pool, total size = 21474836480, chunk size = 134217728
2022-10-15  1:49:09 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-15  1:49:09 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1154734637796,1154927675978
2022-10-15  1:49:17 0 [Note] InnoDB: Starting final batch to recover  206326 pages from redo log.
2022-10-15  1:49:24 0 [Note] InnoDB: To recover: 80860 pages from log
2022-10-15  1:49:30 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000667', position 364173328
2022-10-15  1:49:30 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-15  1:49:30 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-15  1:49:30 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-15  1:49:30 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-15  1:49:30 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-15  1:49:30 0 [Note] InnoDB: 10.7.4 started; log sequence number 1155277781929; transaction id 2012765458
2022-10-15  1:49:30 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-15  1:49:30 0 [Note] Plugin 'FEEDBACK' is disabled.
221015  1:49:30 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221015  1:49:30 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-15  1:49:30 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-15  1:49:30 0 [Note] Starting table crash recovery...
2022-10-15  1:49:30 0 [Note] Crash table recovery finished.
2022-10-15  1:49:31 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-15  1:49:32 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-15  1:49:32 4 [Note] Started replication for 'profil6a10'
2022-10-15  1:49:33 4 [Note] Started replication for 'profil1a5'
2022-10-15  1:49:33 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-15  1:49:41 0 [Note] InnoDB: Buffer pool(s) load completed at 221015  1:49:41
2022-10-15  1:50:04 154 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000667, 364173328), using_gtid(0), gtid('')
2022-10-18  9:54:42 302736 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000678, 601849658), using_gtid(0), gtid('')
2022-10-18  9:54:53 302750 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000667, 213434790), using_gtid(0), gtid('')
2022-10-18  9:54:59 302756 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000668, 5209734), using_gtid(0), gtid('')
2022-10-18 10:43:15 305707 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000770, 177533714), using_gtid(0), gtid('')
2022-10-18 13:37:31 316340 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000774, 727612565), using_gtid(0), gtid('')
 
 
 
 
 
-----------------------------------
 
 
 
2022-10-20 05:22:04 0x7f2c4dffb700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221020  5:22:04 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=291
max_threads=1002
thread_count=297
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x557ae64f7368
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 = 0x7f2c4dffac98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x557ae2cc093e]
??:0(handle_fatal_signal)[0x557ae27aaa55]
sigaction.c:0(__restore_rt)[0x7f31ad27b140]
linux/raise.c:51(__GI_raise)[0x7f31acdb2ce1]
stdlib/abort.c:81(__GI_abort)[0x7f31acd9c537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x557ae23f5aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x557ae2407406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x557ae2bf9f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x557ae2bfa198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x557ae2bfc3af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x557ae2407f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x557ae23f8acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2baf051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b3c7e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b3f0a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b3f90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b04982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b645ca]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b5caad]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x557ae2b5c692]
??:0(tpool::task_group::execute(tpool::task*))[0x557ae2c58f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x557ae2c5816f]
??:0(std::error_code::default_error_condition() const)[0x7f31ad163ed0]
nptl/pthread_create.c:478(start_thread)[0x7f31ad26fea7]
x86_64/clone.S:97(__GI___clone)[0x7f31ace76aef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-20  5:22:12 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-20  5:22:12 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-20  5:22:12 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-20  5:22:12 0 [Note] InnoDB: Using liburing
2022-10-20  5:22:12 0 [Note] InnoDB: Initializing buffer pool, total size = 21474836480, chunk size = 134217728
2022-10-20  5:22:12 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-20  5:22:12 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1242498441161,1242558156384
2022-10-20  5:22:24 0 [Note] InnoDB: 4 transaction(s) which must be rolled back or cleaned up in total 4 row operations to undo
2022-10-20  5:22:24 0 [Note] InnoDB: Trx id counter is 2382222897
2022-10-20  5:22:24 0 [Note] InnoDB: Starting final batch to recover  225354 pages from redo log.
2022-10-20  5:22:27 0 [Note] InnoDB: To recover: 171111 pages from log
2022-10-20  5:22:41 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000821', position 717069840
2022-10-20  5:22:41 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-20  5:22:41 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-10-20  5:22:41 0 [Note] InnoDB: Rolled back recovered transaction 2382222896
2022-10-20  5:22:41 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-20  5:22:41 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-20  5:22:41 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-20  5:22:41 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-20  5:22:41 0 [Note] InnoDB: 10.7.4 started; log sequence number 1243194792552; transaction id 2382222899
2022-10-20  5:22:41 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-20  5:22:41 0 [Note] Plugin 'FEEDBACK' is disabled.
221020  5:22:41 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221020  5:22:41 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-20  5:22:41 0 [Note] InnoDB: Rolled back recovered transaction 2382222750
2022-10-20  5:22:41 0 [Note] InnoDB: Rolled back recovered transaction 2382222811
2022-10-20  5:22:41 0 [Note] InnoDB: Rolled back recovered transaction 2382222891
2022-10-20  5:22:41 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-10-20  5:22:41 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-20  5:22:41 0 [Note] Starting table crash recovery...
2022-10-20  5:22:41 0 [Note] Crash table recovery finished.
2022-10-20  5:22:43 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-20  5:22:43 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-20  5:22:43 4 [Note] Started replication for 'profil6a10'
2022-10-20  5:22:44 4 [Note] Started replication for 'profil1a5'
2022-10-20  5:22:44 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-20  5:22:51 0 [Note] InnoDB: Buffer pool(s) load completed at 221020  5:22:51
2022-10-20  5:23:06 321 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000821, 717069840), using_gtid(0), gtid('')
2022-10-20  5:23:06 322 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000821, 717069840), using_gtid(0), gtid('')
2022-10-20 13:40:48 30532 [Note] InnoDB: Requested to resize buffer pool. (new size: 17179869184 bytes)
2022-10-20 13:40:48 0 [Note] InnoDB: Resizing buffer pool from 21474836480 to 17179869184 (unit=134217728).
2022-10-20 13:40:48 0 [Note] InnoDB: Disabling adaptive hash index.
2022-10-20 13:40:48 0 [Note] InnoDB: Withdrawing blocks to be shrunken.
2022-10-20 13:40:48 0 [Note] InnoDB: start to withdraw the last 259584 blocks
2022-10-20 13:40:51 0 [Note] InnoDB: withdrawing blocks. (259389/259584)
2022-10-20 13:40:51 0 [Note] InnoDB: withdrew 0 blocks from free list. Tried to relocate 237619 pages (259389/259584)
2022-10-20 13:40:51 0 [Note] InnoDB: withdrawing blocks. (259584/259584)
2022-10-20 13:40:51 0 [Note] InnoDB: withdrew 0 blocks from free list. Tried to relocate 85 pages (259584/259584)
2022-10-20 13:40:51 0 [Note] InnoDB: withdrawn target: 259584 blocks
2022-10-20 13:40:51 0 [Note] InnoDB: Latching whole of buffer pool.
2022-10-20 13:40:51 0 [Note] InnoDB: buffer pool resizing with chunks 160 to 128.
2022-10-20 13:40:51 0 [Note] InnoDB: 32 chunks (259584 blocks) were freed.
2022-10-20 13:40:51 0 [Note] InnoDB: Completed to resize buffer pool from 21474836480 to 17179869184.
2022-10-20 13:40:51 0 [Note] InnoDB: Completed resizing buffer pool at 221020 13:40:51.
2022-10-20 18:15:05 0x7fdd6ffff700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
 
 
 
----------------------------------------
 
 
221020 18:15:05 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=250
max_threads=1002
thread_count=256
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x563f0fa652b8
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 = 0x7fdd6fffec98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x563f0b71693e]
??:0(handle_fatal_signal)[0x563f0b200a55]
sigaction.c:0(__restore_rt)[0x7fe1924cd140]
linux/raise.c:51(__GI_raise)[0x7fe192004ce1]
stdlib/abort.c:81(__GI_abort)[0x7fe191fee537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563f0ae4baa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563f0ae5d406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563f0b64ff87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563f0b650198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563f0b6523af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563f0ae5df19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563f0ae4eacb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b605051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b5927e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b5950a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b59590b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b55a982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b5ba5ca]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b5b2aad]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563f0b5b2692]
??:0(tpool::task_group::execute(tpool::task*))[0x563f0b6aef19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x563f0b6ae16f]
??:0(std::error_code::default_error_condition() const)[0x7fe1923b5ed0]
nptl/pthread_create.c:478(start_thread)[0x7fe1924c1ea7]
x86_64/clone.S:97(__GI___clone)[0x7fe1920c8aef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-20 18:15:11 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-20 18:15:11 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-20 18:15:11 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-20 18:15:11 0 [Note] InnoDB: Using liburing
2022-10-20 18:15:11 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
2022-10-20 18:15:11 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-20 18:15:11 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1253165049460,1253242750414
2022-10-20 18:15:13 0 [Note] InnoDB: Starting final batch to recover  118214 pages from redo log.
2022-10-20 18:15:21 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000842', position 178823496
2022-10-20 18:15:21 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-20 18:15:21 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-20 18:15:21 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-20 18:15:21 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-20 18:15:21 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-20 18:15:21 0 [Note] InnoDB: 10.7.4 started; log sequence number 1253330086527; transaction id 2430969174
2022-10-20 18:15:21 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-20 18:15:21 0 [Note] Plugin 'FEEDBACK' is disabled.
221020 18:15:21 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221020 18:15:21 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-20 18:15:21 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-20 18:15:21 0 [Note] Starting table crash recovery...
2022-10-20 18:15:21 0 [Note] Crash table recovery finished.
2022-10-20 18:15:22 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-20 18:15:22 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-20 18:15:22 4 [Note] Started replication for 'profil6a10'
2022-10-20 18:15:22 4 [Note] Started replication for 'profil1a5'
2022-10-20 18:15:23 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-20 18:15:31 0 [Note] InnoDB: Buffer pool(s) load completed at 221020 18:15:31
2022-10-20 18:16:05 362 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000842, 178823496), using_gtid(0), gtid('')
2022-10-20 18:16:05 363 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000842, 178823496), using_gtid(0), gtid('')
2022-10-22 10:31:01 0x7fac70cf3700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221022 10:31:01 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=402
max_threads=1002
thread_count=408
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x55e21c3e8f28
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 = 0x7fac70cf2c98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55e21921b93e]
??:0(handle_fatal_signal)[0x55e218d05a55]
sigaction.c:0(__restore_rt)[0x7fb0a26d2140]
linux/raise.c:51(__GI_raise)[0x7fb0a2209ce1]
stdlib/abort.c:81(__GI_abort)[0x7fb0a21f3537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e218950aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e218962406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e219154f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e219155198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55e2191573af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e218962f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55e218953ab4]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e21910a051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e219099200]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e219099f7e]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e21909a90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e21905f982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55e2190b7778]
??:0(tpool::task_group::execute(tpool::task*))[0x55e2191b3f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x55e2191b316f]
??:0(std::error_code::default_error_condition() const)[0x7fb0a25baed0]
nptl/pthread_create.c:478(start_thread)[0x7fb0a26c6ea7]
x86_64/clone.S:97(__GI___clone)[0x7fb0a22cdaef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-10-22 10:31:08 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-22 10:31:08 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-22 10:31:08 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-22 10:31:08 0 [Note] InnoDB: Using liburing
2022-10-22 10:31:08 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
2022-10-22 10:31:08 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-22 10:31:08 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1279011534481,1279060209400
2022-10-22 10:31:13 0 [Note] InnoDB: 2 transaction(s) which must be rolled back or cleaned up in total 2 row operations to undo
2022-10-22 10:31:13 0 [Note] InnoDB: Trx id counter is 2535354374
2022-10-22 10:31:13 0 [Note] InnoDB: Starting final batch to recover  168297 pages from redo log.
2022-10-22 10:31:23 0 [Note] InnoDB: To recover: 39740 pages from log
2022-10-22 10:31:26 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.000886', position 457264544
2022-10-22 10:31:26 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-22 10:31:26 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-10-22 10:31:26 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-22 10:31:26 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-22 10:31:26 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-22 10:31:26 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-22 10:31:26 0 [Note] InnoDB: Rolled back recovered transaction 2535354362
2022-10-22 10:31:26 0 [Note] InnoDB: Rolled back recovered transaction 2535354367
2022-10-22 10:31:26 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-10-22 10:31:26 0 [Note] InnoDB: 10.7.4 started; log sequence number 1279316416670; transaction id 2535354377
2022-10-22 10:31:26 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-10-22 10:31:26 0 [Note] Plugin 'FEEDBACK' is disabled.
221022 10:31:26 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221022 10:31:26 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-10-22 10:31:26 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-10-22 10:31:26 0 [Note] Starting table crash recovery...
2022-10-22 10:31:26 0 [Note] Crash table recovery finished.
2022-10-22 10:31:28 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-22 10:31:28 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-10-22 10:31:28 4 [Note] Started replication for 'profil6a10'
2022-10-22 10:31:29 4 [Note] Started replication for 'profil1a5'
2022-10-22 10:31:29 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-10-22 10:31:37 0 [Note] InnoDB: Buffer pool(s) load completed at 221022 10:31:37
2022-10-22 10:32:02 286 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.000886, 457264544), using_gtid(0), gtid('')
2022-10-22 10:32:02 287 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000886, 457264544), using_gtid(0), gtid('')
2022-10-22 17:06:16 24349 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.000895, 768627788), using_gtid(0), gtid('')
2022-10-28  9:01:40 521887 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.001056, 969901453), using_gtid(0), gtid('')
2022-10-28  9:01:40 521886 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.001056, 981803795), using_gtid(0), gtid('')
2022-10-31 16:26:19 812297 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.001158, 966187673), using_gtid(0), gtid('')
2022-11-02  4:09:34 943120 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.001205, 854203421), using_gtid(0), gtid('')
2022-11-06 19:16:03 0x7eff857fa700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221106 19:16:03 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=369
max_threads=1002
thread_count=375
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x563ce5b0a548
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 = 0x7eff857f9c98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x563ce295993e]
??:0(handle_fatal_signal)[0x563ce2443a55]
sigaction.c:0(__restore_rt)[0x7f03f39a9140]
linux/raise.c:51(__GI_raise)[0x7f03f34e0ce1]
stdlib/abort.c:81(__GI_abort)[0x7f03f34ca537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563ce208eaa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563ce20a0406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563ce2892f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563ce2893198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x563ce28953af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563ce20a0f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x563ce2091acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce2848051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27d57e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27d80a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27d890b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce279d982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27fd5ca]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27f5aad]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x563ce27f5692]
??:0(tpool::task_group::execute(tpool::task*))[0x563ce28f1f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x563ce28f116f]
??:0(std::error_code::default_error_condition() const)[0x7f03f3891ed0]
nptl/pthread_create.c:478(start_thread)[0x7f03f399dea7]
x86_64/clone.S:97(__GI___clone)[0x7f03f35a4aef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-11-06 19:16:10 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-11-06 19:16:10 0 [Note] InnoDB: Number of transaction pools: 1
2022-11-06 19:16:10 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-11-06 19:16:10 0 [Note] InnoDB: Using liburing
2022-11-06 19:16:10 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
2022-11-06 19:16:10 0 [Note] InnoDB: Completed initialization of buffer pool
2022-11-06 19:16:10 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=1549195755923,1549256634623
2022-11-06 19:16:11 0 [Note] InnoDB: 3 transaction(s) which must be rolled back or cleaned up in total 3 row operations to undo
2022-11-06 19:16:11 0 [Note] InnoDB: Trx id counter is 3686753506
2022-11-06 19:16:11 0 [Note] InnoDB: Starting final batch to recover  76821 pages from redo log.
2022-11-06 19:16:17 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.001365', position 230442724
2022-11-06 19:16:17 0 [Note] InnoDB: 128 rollback segments are active.
2022-11-06 19:16:17 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-11-06 19:16:17 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-11-06 19:16:17 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-11-06 19:16:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-11-06 19:16:17 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-11-06 19:16:17 0 [Note] InnoDB: 10.7.4 started; log sequence number 1549296547637; transaction id 3686753507
2022-11-06 19:16:17 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-11-06 19:16:17 0 [Note] Plugin 'FEEDBACK' is disabled.
221106 19:16:17 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221106 19:16:17 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-11-06 19:16:17 0 [Note] InnoDB: Rolled back recovered transaction 3686753462
2022-11-06 19:16:17 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-11-06 19:16:17 0 [Note] Starting table crash recovery...
2022-11-06 19:16:17 0 [Note] Crash table recovery finished.
2022-11-06 19:16:17 0 [Note] InnoDB: Rolled back recovered transaction 3686753460
2022-11-06 19:16:17 0 [Note] InnoDB: Rolled back recovered transaction 3686753496
2022-11-06 19:16:17 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-11-06 19:16:17 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-11-06 19:16:18 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-11-06 19:16:18 4 [Note] Started replication for 'profil6a10'
2022-11-06 19:16:18 4 [Note] Started replication for 'profil1a5'
2022-11-06 19:16:19 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-11-06 19:16:27 0 [Note] InnoDB: Buffer pool(s) load completed at 221106 19:16:27
2022-11-06 19:17:04 435 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.001365, 230442724), using_gtid(0), gtid('')
2022-11-06 19:17:04 436 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.001365, 230442724), using_gtid(0), gtid('')
2022-11-26  7:02:28 1713525 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002030, 104384744), using_gtid(0), gtid('')
2022-11-29  4:00:27 1965761 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002155, 64527248), using_gtid(0), gtid('')
2022-11-30  0:03:36 2039189 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002191, 912737640), using_gtid(0), gtid('')
2022-12-01 05:08:01 0x7fc0337fe700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221201  5:08:01 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=465
max_threads=1002
thread_count=471
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x559f3d2c7728
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 = 0x7fc0337fdc98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x559f39cbd93e]
??:0(handle_fatal_signal)[0x559f397a7a55]
sigaction.c:0(__restore_rt)[0x7fc47b312140]
linux/raise.c:51(__GI_raise)[0x7fc47ae49ce1]
stdlib/abort.c:81(__GI_abort)[0x7fc47ae33537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x559f393f2aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x559f39404406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x559f39bf6f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x559f39bf7198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x559f39bf93af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x559f39404f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x559f393f5acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39bac051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b3b200]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b3bf7e]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b3c90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b01982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b615ca]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b59aad]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x559f39b59692]
??:0(tpool::task_group::execute(tpool::task*))[0x559f39c55f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x559f39c5516f]
??:0(std::error_code::default_error_condition() const)[0x7fc47b1faed0]
nptl/pthread_create.c:478(start_thread)[0x7fc47b306ea7]
x86_64/clone.S:97(__GI___clone)[0x7fc47af0daef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-12-01  5:08:08 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-12-01  5:08:08 0 [Note] InnoDB: Number of transaction pools: 1
2022-12-01  5:08:08 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-12-01  5:08:08 0 [Note] InnoDB: Using liburing
2022-12-01  5:08:08 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
2022-12-01  5:08:08 0 [Note] InnoDB: Completed initialization of buffer pool
2022-12-01  5:08:08 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2044498938951,2044600246723
2022-12-01  5:08:20 0 [Note] InnoDB: 3 transaction(s) which must be rolled back or cleaned up in total 3 row operations to undo
2022-12-01  5:08:20 0 [Note] InnoDB: Trx id counter is 5778431751
2022-12-01  5:08:20 0 [Note] InnoDB: Starting final batch to recover  241859 pages from redo log.
2022-12-01  5:08:23 0 [Note] InnoDB: To recover: 187739 pages from log
2022-12-01  5:08:38 0 [Note] InnoDB: To recover: 7222 pages from log
2022-12-01  5:08:38 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.002239', position 144969694
2022-12-01  5:08:38 0 [Note] InnoDB: 128 rollback segments are active.
2022-12-01  5:08:38 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-12-01  5:08:38 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-12-01  5:08:38 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-12-01  5:08:38 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-12-01  5:08:38 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-12-01  5:08:38 0 [Note] InnoDB: Rolled back recovered transaction 5778431750
2022-12-01  5:08:38 0 [Note] InnoDB: Rolled back recovered transaction 5778431703
2022-12-01  5:08:38 0 [Note] InnoDB: 10.7.4 started; log sequence number 2045248732182; transaction id 5778431754
2022-12-01  5:08:38 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-12-01  5:08:38 0 [Note] Plugin 'FEEDBACK' is disabled.
221201  5:08:38 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221201  5:08:38 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-12-01  5:08:38 0 [Note] InnoDB: Rolled back recovered transaction 5778431745
2022-12-01  5:08:38 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-12-01  5:08:38 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-12-01  5:08:38 0 [Note] Starting table crash recovery...
2022-12-01  5:08:38 0 [Note] Crash table recovery finished.
2022-12-01  5:08:39 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-12-01  5:08:40 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-12-01  5:08:40 4 [Note] Started replication for 'profil6a10'
2022-12-01  5:08:40 4 [Note] Started replication for 'profil1a5'
2022-12-01  5:08:41 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-12-01  5:08:49 0 [Note] InnoDB: Buffer pool(s) load completed at 221201  5:08:49
2022-12-01  5:09:03 158 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002239, 144969694), using_gtid(0), gtid('')
2022-12-01  5:09:03 159 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.002239, 144969694), using_gtid(0), gtid('')
2022-12-01 22:19:19 62423 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002277, 722904534), using_gtid(0), gtid('')
2022-12-09  0:06:58 681858 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002556, 791240996), using_gtid(0), gtid('')
2022-12-09 08:58:06 0x7faac27fc700  InnoDB: Assertion failure in file ./storage/innobase/fil/fil0fil.cc line 484
InnoDB: Failing assertion: space->is_ready_to_close() || space->purpose == FIL_TYPE_TEMPORARY || srv_fast_shutdown == 2 || !srv_was_started
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.
221209  8:58:06 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
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.7.4-MariaDB-1:10.7.4+maria~bullseye-log
key_buffer_size=134217728
read_buffer_size=2097152
max_used_connections=406
max_threads=1002
thread_count=408
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6313675 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x55afe0b6c028
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 = 0x7faac27fbc98 thread_stack 0x49000
??:0(my_print_stacktrace)[0x55afdd6de93e]
??:0(handle_fatal_signal)[0x55afdd1c8a55]
sigaction.c:0(__restore_rt)[0x7faf15639140]
linux/raise.c:51(__GI_raise)[0x7faf15170ce1]
stdlib/abort.c:81(__GI_abort)[0x7faf1515a537]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55afdce13aa5]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55afdce25406]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55afdd617f87]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55afdd618198]
??:0(std::thread::thread<void (&)(), , void>(void (&)()))[0x55afdd61a3af]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55afdce25f19]
??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x55afdce16acb]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd5cd051]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd55a7e3]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd55d0a7]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd55d90b]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd522982]
??:0(void std::this_thread::sleep_for<long, std::ratio<1l, 1l> >(std::chrono::duration<long, std::ratio<1l, 1l> > const&))[0x55afdd57a778]
??:0(tpool::task_group::execute(tpool::task*))[0x55afdd676f19]
??:0(tpool::thread_pool_generic::worker_main(tpool::worker_data*))[0x55afdd67616f]
??:0(std::error_code::default_error_condition() const)[0x7faf15521ed0]
nptl/pthread_create.c:478(start_thread)[0x7faf1562dea7]
x86_64/clone.S:97(__GI___clone)[0x7faf15234aef]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0): (null)
Connection ID (thread ID): 0
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,not_null_range_scan=off
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: 
 
Writing a core file...
Working directory at /srv/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128370               128370               processes 
Max open files            32768                32768                files     
Max locked memory         524288               524288               bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128370               128370               signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: core
 
2022-12-09  8:58:13 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-12-09  8:58:13 0 [Note] InnoDB: Number of transaction pools: 1
2022-12-09  8:58:13 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-12-09  8:58:13 0 [Note] InnoDB: Using liburing
2022-12-09  8:58:13 0 [Note] InnoDB: Initializing buffer pool, total size = 17179869184, chunk size = 134217728
2022-12-09  8:58:13 0 [Note] InnoDB: Completed initialization of buffer pool
2022-12-09  8:58:13 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2230309663824,2230355164840
2022-12-09  8:58:19 0 [Note] InnoDB: 3 transaction(s) which must be rolled back or cleaned up in total 3 row operations to undo
2022-12-09  8:58:19 0 [Note] InnoDB: Trx id counter is 6555468206
2022-12-09  8:58:19 0 [Note] InnoDB: Starting final batch to recover  190167 pages from redo log.
2022-12-09  8:58:28 0 [Note] InnoDB: To recover: 77774 pages from log
2022-12-09  8:58:35 0 [Note] InnoDB: Last binlog file '/srv/mysql/binlog/mariadb-bin.002565', position 317675004
2022-12-09  8:58:35 0 [Note] InnoDB: 128 rollback segments are active.
2022-12-09  8:58:35 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-12-09  8:58:35 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-12-09  8:58:35 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-12-09  8:58:35 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-12-09  8:58:35 0 [Note] InnoDB: Rolled back recovered transaction 6555468203
2022-12-09  8:58:35 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-12-09  8:58:35 0 [Note] InnoDB: 10.7.4 started; log sequence number 2230661376497; transaction id 6555468208
2022-12-09  8:58:35 0 [Note] InnoDB: Loading buffer pool(s) from /srv/mysql/data/ib_buffer_pool
2022-12-09  8:58:35 0 [Note] Plugin 'FEEDBACK' is disabled.
221209  8:58:35 server_audit: MariaDB Audit Plugin version 1.4.14 STARTED.
221209  8:58:35 server_audit: logging started to the file /srv/mysql/log/audit.log.
2022-12-09  8:58:35 0 [Note] InnoDB: Rolled back recovered transaction 6555468164
2022-12-09  8:58:35 0 [Note] InnoDB: Rolled back recovered transaction 6555468154
2022-12-09  8:58:35 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-12-09  8:58:35 0 [Note] Recovering after a crash using /srv/mysql/binlog/mariadb-bin
2022-12-09  8:58:35 0 [Note] Starting table crash recovery...
2022-12-09  8:58:35 0 [Note] Crash table recovery finished.
2022-12-09  8:58:37 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-12-09  8:58:37 2 [Note] Event Scheduler: scheduler thread started with id 2
2022-12-09  8:58:37 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.7.4-MariaDB-1:10.7.4+maria~bullseye-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2022-12-09  8:58:46 0 [Note] InnoDB: Buffer pool(s) load completed at 221209  8:58:45
2022-12-09  8:59:07 435 [Note] Start binlog_dump to slave_server(3454991215), pos(mariadb-bin.002565, 317675004), using_gtid(0), gtid('')
2022-12-09  8:59:07 436 [Note] Start binlog_dump to slave_server(3871582380), pos(mariadb-bin.002565, 317675004), using_gtid(0), gtid('')

On last crash innodb_buffer_pool_size was really low to exclude any trouble with memory.



 Comments   
Comment by Aurélien LEQUOY [ 2022-12-09 ]

my.cnf

# MariaDB database server configuration file.
#
# You can copy this file to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
 
# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock
 
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
 
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0
 
[mysqld]
#
# * Basic Settings
#
#read_only=1
 
profil1a5.replicate_do_db=pc_profiles1
profil1a5.replicate_do_db=pc_profiles2
profil1a5.replicate_do_db=pc_profiles3
profil1a5.replicate_do_db=pc_profiles4
profil1a5.replicate_do_db=pc_profiles5
 
 
profil6a10.replicate_do_db=pc_profiles6
profil6a10.replicate_do_db=pc_profiles7
profil6a10.replicate_do_db=pc_profiles8
profil6a10.replicate_do_db=pc_profiles9
profil6a10.replicate_do_db=pc_profiles10
 
innodb_autoextend_increment = 1000
innodb_strict_mode=0
sql_mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
performance_schema=ON
connect_timeout=10
innodb_rollback_on_timeout=1
wait_timeout=18000
 
 
plugin-load=server_audit=server_audit.so
 
server_audit_logging=1
 
# do not allow users to uninstall plugin
server_audit=FORCE_PLUS_PERMANENT
 
# only audit connections and DDL queries
server_audit_events=CONNECT,QUERY_DDL
 
# flat file
server_audit_output_type=FILE
server_audit_file_path=/srv/mysql/log/audit.log
server_audit_file_rotate_size=1000000
server_audit_file_rotations=9
 
 
 
character-set-server  = utf8mb4 
collation-server      = utf8mb4_general_ci 
character_set_server   = utf8mb4
collation-server = utf8mb4_general_ci
#innodb_force_recovery = 1
 
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /srv/mysql/data
tmpdir          = /srv/mysql/tmp
lc_messages_dir = /usr/share/mysql
lc_messages     = en_US
 
plugin_dir = /usr/lib/mysql/plugin/
 
skip-name-resolve
 
#logs
log_error=/srv/mysql/log/error.log
 
 
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
# bind-address           = 127.0.0.1
#
# * Fine Tuning
#
max_connections         = 1000
connect_timeout         = 10
#wait_timeout            = 18000
max_allowed_packet      = 256M
thread_cache_size       = 128
sort_buffer_size        = 4M
bulk_insert_buffer_size = 16M
tmp_table_size          = 256M
max_heap_table_size     = 256M
#
# * MyISAM
#
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched. On error, make copy and try a repair.
myisam_recover_options = BACKUP
key_buffer_size         = 128M
open-files-limit       = 2000
table_open_cache        = 400
myisam_sort_buffer_size = 512M
concurrent_insert       = 2
read_buffer_size        = 2M
read_rnd_buffer_size    = 1M
key_cache_segments      = 64
 
#mroonga.replicate_rewrite_db="repl->repl2"
#mroonga.replicate_do_table="repl2.article2"
 
#
# * Query Cache Configuration
#
# Cache only tiny result sets, so we can fit more in the query cache.
query_cache_limit               = 128K
query_cache_size                = 0
# for more write intensive setups, set to DEMAND or OFF
query_cache_type                = OFF
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
general_log_file        = /srv/mysql/log/general.log
#general_log             = 1
#
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# we do want to know about network errors and such
log_warnings            = 2
#
# Enable the slow query log to see queries with especially long duration
slow_query_log=1
slow_query_log_file     = /srv/mysql/mariadb-slow.log
long_query_time=0.1
#log_slow_rate_limit    = 1000
log_slow_verbosity      = query_plan
log_slave_updates       = 1
#log-queries-not-using-indexes
#log_slow_admin_statements
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
server-id               = 4292385261
 
report_host            = gcp-prod-oos-sql-0001-mariadb-g02-001
 
#auto_increment_increment = 2
#auto_increment_offset  = 1
log_bin                        = /srv/mysql/binlog/mariadb-bin
log_bin_index          = /srv/mysql/binlog/mariadb-bin.index
# not fab for performance, but safer
#sync_binlog            = 1
expire_logs_days        = 10
max_binlog_size         = 1G
 
# slaves
relay_log              = /srv/mysql/relaylog/relay-bin
relay_log_index        = /srv/mysql/relaylog/relay-bin.index
relay_log_info_file   = /srv/mysql/relaylog/relay-bin.info
 
log_slave_updates
 
#read_only
 
#
# If applications support it, this stricter sql_mode prevents some
# mistakes like inserting invalid dates etc.
# sql_mode               = NO_ENGINE_SUBSTITUTION,TRADITIONAL
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
default_storage_engine  = InnoDB
# you can't just change log file size, requires special procedure
innodb_log_file_size    = 2G
innodb_buffer_pool_size = 16G
#innodb_buffer_pool_instances=8 ## removed for 10.7
innodb_log_buffer_size  = 8M
innodb_file_per_table   = 1
innodb_open_files       = 400
innodb_io_capacity      = 2000
innodb_flush_method     = O_DIRECT
#
# * Security Features
 
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem
 
 
 
#
# * Galera-related settings
event-scheduler = ON
#
 
 
[galera]
# Mandatory settings
wsrep_on=OFF
wsrep_cluster_name='*******'
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://
wsrep_node_address=********
wsrep_node_name=gcp-prod-oos-sql-0001-mariadb-g02-001
wsrep_gtid_mode=ON
 
wsrep_sst_method = xtrabackup-v2
wsrep_sst_auth = 'sst:*******'
 
wsrep_provider_options="gcache.size = 20G"
wsrep_max_ws_rows = 500000
 
 
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
 
#
# Allow server to accept connections on all interfaces.
#
bind-address=0.0.0.0
#
# Optional setting
wsrep_slave_threads=4
innodb_flush_log_at_trx_commit=2
 
# DBUG options for wsrep provider
#wsrep_dbug_option
 
# Generate fake primary keys for non-PK tables (required for multi-master
# and parallel applying operation)
wsrep_certify_nonPK=1
 
# Location of the directory with data files. Needed for non-mysqldump
# state snapshot transfers. Defaults to mysql_real_data_home.
#wsrep_data_home_dir=
 
# Maximum number of rows in write set
wsrep_max_ws_rows=131072
 
# Maximum size of write set
wsrep_max_ws_size=1073741824
 
# to enable debug level logging, set this to 1
wsrep_debug=0
 
# convert locking sessions into transactions
wsrep_convert_LOCK_to_trx=0
 
# how many times to retry deadlocked autocommits
wsrep_retry_autocommit=1
 
# change auto_increment_increment and auto_increment_offset automatically
wsrep_auto_increment_control=1
 
# replicate myisam
## wsrep_replicate_myisam=1 #removed in 10.7
 
 
 
# retry autoinc insert, which failed for duplicate key error
wsrep_drupal_282555_workaround=0
 
# enable "strictly synchronous" semantics for read operations
wsrep_causal_reads=0
 
# Protocol version to use
# wsrep_protocol_version=
 
# log conflicts
wsrep_log_conflicts=1
 
 
 
[xtrabackup]
user=sst
password=QSEDWGRg133
databases-exclude=lost+found
 
[mysqldump]
quick
quote-names
max_allowed_packet      = 256M
 
[mysql]
#no-auto-rehash # faster start of mysql but no tab completion
 
[isamchk]
key_buffer              = 16M
 
!includedir /etc/mysql/conf.d/

Comment by Alice Sherepa [ 2022-12-12 ]

Could you please upgrade to the latest version - this might be MDEV-26293 (10.7.5)

Comment by Aurélien LEQUOY [ 2022-12-20 ]

I don't have any partitions in this server, it's even happen on a slave who do nothing.

Generated at Thu Feb 08 10:14:19 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.