There are know problems with innodb_adaptive_hash_index; see MDEV-20487 and related bugs.

Dermot.Brereton, if you see hangs with innodb_adaptive_hash_index=0, please run

gdb -ex "set pagination 0" -ex "thread apply all bt" -ex "print dict_operation_lock" -ex "print dict_sys->mutex" --batch -p $(pgrep -x mysqld)

and try to create and preserve a core dump for further analysis.

I have no evidence from the attached logs that this issue is related to innodb_adaptive_hash_index

Do you recommend setting innodb_adaptive_hash_index = 0 (the current value is 1)?

Also based on the information provided in the attached syslog's is this issue similar to MDEV-13983?

Dermot.Brereton, it is hard to analyze hangs solely based on server error log output. It could easily take more than 1 hour of my time, and still the cause could remain unresolved. Stack traces of all threads are a much more convenient and reliable way of analyzing hangs. I cannot say for sure which hang reports are related, because I have not seen the requested gdb output in any of them.

My motivation to disable the adaptive hash index in MariaDB Server 10.5 by default (MDEV-20487) is the bugs that we are aware of, but have not had time to fix yet. In fact, I would have disabled it at compilation time, but we got some user and customer feedback that it can actually help the performance of read-mostly workloads.

Your crash could have the same underlying reason as in MDEV-16467 that was fixed in 10.2.25

Try upgrading

Issue was resolved when the DRBD replication software was removed from the database server and the data file system created as ext4.

This ticket can now be closed.