Mysql travando: [FATAL] A espera do semáforo durou> 600 segundos

Uma vez por dia ou dois, obtemos o erro abaixo e o mysql trava:

2024-07-14T05:31:59.327696Z 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2024-07-14T05:31:59.327741Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: srv0srv.cc:1878:ib::fatal triggered thread 140039700203264
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-07-14T05:31:59Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=1758de1e111952b1f61480360c447dc27d6caddc
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x2130f51]
/usr/sbin/mysqld(print_fatal_signal(int)+0x397) [0xfee797]
/usr/sbin/mysqld(my_server_abort()+0x75) [0xfee8e5]
/usr/sbin/mysqld(my_abort()+0xe) [0x212adee]
usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x309) [0x237b9b9]
/usr/sbin/mysqld(ib::fatal::~fatal()+0xcf) [0x237e2ff]
/usr/sbin/mysqld(srv_error_monitor_thread()+0x7aa) [0x231c41a]
/usr/sbin/mysqld(void Detached_thread::operator()<void (*)()>(void (*&&)())+0xca) [0x224a87a]
/lib64/libstdc++.so.6(+0xc2b13) [0x7f5de9854b13]
/lib64/libpthread.so.0(+0x81da) [0x7f5dea8bc1da]
/lib64/libc.so.6(clone+0x43) [0x7f5de8e6be73]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

E antes há muitos deles:

Mutex at 0x7fde903975e8, Mutex TRX_SYS created trx0sys.cc:565, locked by 140504716736256
--Thread 140504724723456 has waited at trx0sys.h line 598 for 240 seconds the semaphore:
2024-07-13T04:43:26.039036Z 0 [Warning] [MY-012985] [InnoDB] A long semaphore wait:
{}

Também vejo muitos desses avisos nos logs (acho que principalmente após a reinicialização):

[Warning] [MY-013865] [InnoDB] Redo log writer is waiting for a new redo log file. Consider increasing innodb_redo_log_capacity.

Não consegui descobrir qual é a causa desse problema. Aumentei innodb_redo_log_capacitymuito, mas aconteceu mesmo assim. Eu também tentei desligar, innodb_adaptive_hash_indexmas não ajudou. Pensei em aumentar innodb_log_buffer_sizeo que atualmente está definido para 1 milhão porque pensei que talvez isso estivesse causando lentidão na transação.

É importante dizer que o MySQL parece parar de fazer qualquer coisa nesses 600 segundos. Não consigo me conectar ao servidor neste momento, a CPU está reduzida a nada e então recebemos esse erro e uma queda. Como não é possível conectar-se ao banco de dados durante o tempo de inatividade, pensei que executar um evento agendado do próprio MySQL, escrevendo consultas em execução no disco, deveria resolver o problema - mas eu estava errado. Mesmo o uso de um evento agendado parou de gravar no mesmo horário em que o tempo de inatividade começou. Outra coisa que tentei é habilitar innodb_status_outputquais logs SHOW ENGINE INNODB STATUS;a stderrcada 15 segundos, mesmo isso parou de gravar ao stderrmesmo tempo em que o tempo de inatividade começou.

Usamos a versão MySQL8.0.34