Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-30185

Crash MariaDB in cascade

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.7.4
    • None
    • Server
    • None
    • 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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            Aurelien_LEQUOY Aurélien LEQUOY
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.