Bug #91941 Deadlock during purge_logs_before_date
Submitted: 9 Aug 2018 4:27 Modified: 25 Sep 2018 11:11
Reporter: Nikolai Ikhalainen Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Logging Severity:S2 (Serious)
Version:5.7.23 OS:Ubuntu (16.04)
Assigned to: CPU Architecture:Any

[9 Aug 2018 4:27] Nikolai Ikhalainen
Description:
There threads awaiting on binary-log related locks
      8 pthread_cond_wait,native_cond_wait(thr_cond.h:140),my_cond_wait(thr_cond.h:140),inline_mysql_cond_wait(thr_cond.h:140),Stage_manager::enroll_for(thr_cond.h:140),MYSQL_BIN_LOG::change_stage(binlog.cc:9026),MYSQL_BIN_LOG::ordered_commit(binlog.cc:9436),MYSQL_BIN_LOG::commit(binlog.cc:8725),ha_commit_trans(handler.cc:1798),trans_commit_stmt(transaction.cc:458),mysql_execute_command(sql_parse.cc:4976),mysql_parse(sql_parse.cc:5554),dispatch_command(sql_parse.cc:1484),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)
      2 __lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),MYSQL_BIN_LOG::lock_index(thr_mutex.h:84),Binlog_sender::run(thr_mutex.h:84),mysql_binlog_send(rpl_master.cc:412),com_binlog_dump(rpl_master.cc:341),dispatch_command(sql_parse.cc:1706),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)
      1 __lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),MYSQL_BIN_LOG::lock_index(thr_mutex.h:84),show_binlogs(thr_mutex.h:84),mysql_execute_command(sql_parse.cc:3503),mysql_parse(sql_parse.cc:5554),dispatch_command(sql_parse.cc:1484),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)
      1 __lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),MYSQL_BIN_LOG::change_stage(thr_mutex.h:84),MYSQL_BIN_LOG::ordered_commit(binlog.cc:9436),MYSQL_BIN_LOG::commit(binlog.cc:8725),ha_commit_trans(handler.cc:1798),trans_commit_stmt(transaction.cc:458),mysql_execute_command(sql_parse.cc:4976),mysql_parse(sql_parse.cc:5554),dispatch_command(sql_parse.cc:1484),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)
      1 __lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),Adjust_offset::operator()(thr_mutex.h:84),Do_THD::operator(mysqld_thd_manager.cc:46),std::for_each<THD**,(mysqld_thd_manager.cc:46),Global_THD_manager::do_for_all_thd(mysqld_thd_manager.cc:46),adjust_linfo_offsets(binlog.cc:2801),MYSQL_BIN_LOG::remove_logs_from_index(binlog.cc:2801),MYSQL_BIN_LOG::purge_logs(binlog.cc:6290),MYSQL_BIN_LOG::purge_logs_before_date(binlog.cc:6754),MYSQL_BIN_LOG::ordered_commit(binlog.cc:9660),MYSQL_BIN_LOG::commit(binlog.cc:8725),ha_commit_trans(handler.cc:1798),trans_commit(transaction.cc:239),Xid_log_event::do_commit(log_event.cc:7090),Xid_apply_log_event::do_apply_event(log_event.cc:7330),Log_event::apply_event(log_event.cc:3354),apply_event_and_update_pos(rpl_slave.cc:4719),exec_relay_log_event(rpl_slave.cc:5257),handle_slave_sql(rpl_slave.cc:5257),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)

Many others awaiting for &LOCK_global_system_variables (mostly THD::init).

There are 512 binary log files, expire_logs_days = 7
System running under 60 insert statements per second, 125 updates per second 

How to repeat:
The problem happens with production slave server
[9 Aug 2018 4:30] Nikolai Ikhalainen
stack trace deadlock on slave during binlog purge

Attachment: bt.txt (text/plain), 1.01 MiB.

[10 Aug 2018 12:59] MySQL Verification Team
Hi,

Thank you for your report.

I must admit that I do not see any deadlocks in your stack trace. There are simply too many threads that are started. Many are awaiting on the OS to create a new thread, while also there are many others who are awaiting on the binary log. There are simply two huge queues waiting on couple of resources. One of the resource is a thread library and other is a binary log that is dumped to and read from.

This all could be caused by the misconfiguration of MySQL server or on OS. How many open file handles MySQL has on its disposal ??? Looks like it is starved out of file handles. Do not forget that each new connection consumes, at least, two file handles.

You should definitely limit number of threads. You should not use thread cache, but you should use Thread Pool Plugin and configure it properly.

Regarding binary log, you should limit their sizes further and re-configure its entire handling.

Simply, to me this does not look like a bug, but like a mis-configuration.
[10 Aug 2018 15:11] lalit Choudhary
Looking at the backtrace of https://bugs.mysql.com/bug.php?id=71901 there are few similarities.
[10 Aug 2018 15:20] MySQL Verification Team
Hi,

No, it is not similar, since in this one there is no unlink() call in any of the threads.

Also, the priority of the mentioned bug is very low, since reducing the maximum binary log file size, which I already recommended, makes the problem disappear.
[11 Aug 2018 3:36] Nikolai Ikhalainen
Hi,

There are just 14 threads executing commands:
grep do_command bt.txt|wc -l
14

Another 12 trying to finish:
grep remove_thd bt.txt |wc -l
12
(11 awaiting on &LOCK_thd_remove, one on &LOCK_thd_list)

Most of threads you seeing created just because they can't get mysql_mutex_lock(&LOCK_global_system_variables);
grep -F sql/sql_class.cc:1521 bt.txt |wc -l
534

As I understand it should be locked by $10 = 0x7f96343f5900 "SHOW VARIABLES WHERE Variable_Name='userstat'\n\t\tOR Variable_Name='userstat_running'":
1 __lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),PolyLock_lock_log::rdlock(thr_mutex.h:84),AutoRLock::AutoRLock(sys_vars_shared.h:89),sys_var::value_ptr(sys_vars_shared.h:89),get_one_variable_ext(sql_show.cc:2856),System_variable::init(pfs_variable.cc:537),PFS_system_variable_cache::do_materialize_all(pfs_variable.cc:231),PFS_variable_cache::materialize_all(pfs_variable.h:530),table_session_variables::rnd_init(pfs_variable.h:530),ha_perfschema::rnd_init(ha_perfschema.cc:323),handler::ha_rnd_init(handler.cc:2897),init_read_record(records.cc:314),join_init_read_record(sql_executor.cc:2480),sub_select(sql_executor.cc:1277),do_select(sql_executor.cc:950),JOIN::exec(sql_executor.cc:950),TABLE_LIST::materialize_derived(sql_derived.cc:326),join_materialize_derived(sql_executor.cc:2502),QEP_TAB::prepare_scan(sql_executor.cc:1331),sub_select(sql_executor.cc:1231),do_select(sql_executor.cc:950),JOIN::exec(sql_executor.cc:950),handle_query(sql_select.cc:184),execute_sqlcom_select(sql_parse.cc:5128),mysql_execute_command(sql_parse.cc:2814),mysql_parse(sql_parse.cc:5554),dispatch_command(sql_parse.cc:1484),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)

because it checks:
    mysql_mutex_assert_owner(&LOCK_global_system_variables);
    AutoRLock lock(guard);

Binary log mutex obtained by:
__lll_lock_wait(libpthread.so.0),pthread_mutex_lock(libpthread.so.0),native_mutex_lock(thr_mutex.h:84),my_mutex_lock(thr_mutex.h:84),inline_mysql_mutex_lock(thr_mutex.h:84),MYSQL_BIN_LOG::lock_index(thr_mutex.h:84),show_binlogs(thr_mutex.h:84),mysql_execute_command(sql_parse.cc:3503),mysql_parse(sql_parse.cc:5554),dispatch_command(sql_parse.cc:1484),do_command(sql_parse.cc:1025),handle_connection(connection_handler_per_thread.cc:300),pfs_spawn_thread(pfs.cc:2190),start_thread(libpthread.so.0),clone(libc.so.6)
with mysql_mutex_lock(mysql_bin_log.get_log_lock()); and it's awaiting on mysql_bin_log.lock_index();
This thread running "SHOW BINARY LOGS" command.

I think most interesting action happening here:
thr 30 MYSQL_BIN_LOG::change_stage awaiting on mysql_mutex_lock(enter_mutex);
#4  inline_mysql_mutex_lock (src_file=0x158f3d0 "/build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc", src_line=9040, that=0x1df2e68 <mysql_bin_log+8>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/mysql/psi/mysql_thread.h:715
thr 54 ( Adjust_offset operator)
#4  inline_mysql_mutex_lock (src_file=0x158f3d0 "/build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc", src_line=2759, that=0x7f96341c6730) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/mysql/psi/mysql_thread.h:715

> How many open file handles MySQL has on its disposal ?

max_connections looks oversized for this system:
max_connections = 5000
But number of file descriptors is huge:
(gdb) p open_files_limit
$6 = 1048576
table_cache_size = 2000

> Regarding binary log, you should limit their sizes further and re-configure its entire handling.
Maximum size for binlogs is already small: 100MB
(gdb) p max_binlog_size
$9 = 104857600
[13 Aug 2018 12:05] MySQL Verification Team
Hi,

As I wrote, this is not a bug.

It is simple case where CPU and OS resources are exhausted by a huge number of threads that are running. You should limit maximum number of connections to few hundred and use Thread Pool plugin to optimise your settings according to the number of cores that you have at your disposal.

With this number of threads asking for the same resource, thread library has to scan constantly through thousands and thousands of threads in order to reorder them. Queues are simply huge and your machine and OS simply can't cope with them.

Not a bug.
[15 Aug 2018 6:21] Jean-François Gagné
It is not clear from the description of the bug, but it looks like this slave is running parallel replication with slave_preserve_commit_order.  My understanding from the bug title is that this was triggered by a binlog purging operation, but again, the bug description could be more clear.

There is a good history of deadlock with the slave_preserve_commit_order option, two examples are Bug#86079 and Bug#89247, with the 2nd bug still being opened.  Maybe this is similar to one of those, or a new problem.
[15 Aug 2018 13:20] MySQL Verification Team
It's a deadlock,  not a performance tuning issue.
Saw this mentioned on facebook.
Didn't quite find out the exact cause yet, but here's preliminary finding:

From bt.txt 
------------

all 534 new connections waiting for LOCK_global_system_variables in function THD::init for mysql_mutex_lock(&LOCK_global_system_variables);

Thread 61:  some select from P_S table of variables ( performance_schema.global_variables ??)
     owns LOCK_global_system_variables (acquired in System_variable::init, storage/perfschema/pfs_variable.cc:526 )
     owns one thd's LOCK_thd_sysvar (acquired in System_variable::init, storage/perfschema/pfs_variable.cc:524 )
     owns one thd's LOCK_thd_data (acquired in PFS_system_variable_cache::do_materialize_all, storage/perfschema/pfs_variable.cc:196 )
     waits on a PLock_log for sysvar Binlog_transaction_dependency_history_size ?  who owns this????

Thread 60 + many: destroying a thread...
      owns LOCK_thd_remove
      waits for LOCK_thd_list

Thread 59: show binlogs.
      waits for LOCK_index  [ mysql_bin_log.lock_index();]

Thread 54: commit...
      waits for LOCK_log [

Thread 49: some query selecting a global variable...
      waits for LOCK_global_system_variables

Thread 33 & 34: binlog dump threads.
      waits for LOCK_index

Thread 30: slave sql thread replicating a 'purge binary logs to xxxx' command!
     waits for thd->LOCK_thd_data
     owns LOCK_thd_list
     owns LOCK_index (acquired in MYSQL_BIN_LOG::purge_logs_before_date)

Therefore,  thread 30 waits for thread 61.
thread 61 waits for whatever locks PLock_log for that sysvar????
I couldn't figure out who holds that lock.  Also that variable is new in 5.7.22.
[16 Aug 2018 12:07] MySQL Verification Team
Hi,

We had to do a very careful analysis of your thread stacks in order to discover that this is ultimately a bug.

So we have thread 61 waiting for thread 59, which waits for thread 30 which waits for thread 61 -- classical loop in wait-for graph.

Hence, we are verifying it as a serious bug, leading to the genuine deadlock.

Thank you for your report.
[16 Aug 2018 12:35] Dmitry Lenev
Hello!

A bit more details/analysis of backtrace file provided in the bug report.

There are 3 interesting threads in the backtrace file:

...

Thread 61 (LWP 50116):
#0  0x00007f9c1c17626d in __lll_lock_wait () from /libpthread.so.0
#1  0x00007f9c1c16fdbd in pthread_mutex_lock () from /libpthread.so.0
#2  0x0000000000ce226e in native_mutex_lock (mutex=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:84
#3  my_mutex_lock (mp=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:182
#4  inline_mysql_mutex_lock (src_file=0x1514138 "/build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sys_vars.cc", src_line=3590, that=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/mysql/psi/mysql_thread.h:715
#5  PolyLock_lock_log::rdlock (this=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sys_vars.cc:3590
#6  0x0000000000bc64ae in AutoRLock::AutoRLock (l=0x1de13b0 <PLock_log>, this=<synthetic pointer>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sys_vars_shared.h:89
#7  sys_var::value_ptr (this=0x1de11e0 <Binlog_transaction_dependency_history_size>, running_thd=0x7f96341c5ab0, target_thd=<optimized out>, type=<optimized out>, base=0x7f96cc686b30) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/set_var.cc:272
#8  0x0000000000ca0588 in get_one_variable_ext (running_thd=running_thd@entry=0x7f96341c5ab0, target_thd=target_thd@entry=0x7f96341c5ab0, variable=variable@entry=0x7f9634b59070, value_type=value_type@entry=OPT_SESSION, show_type=<optimized out>, show_type@entry=SHOW_SYS, status_var=status_var@entry=0x0, charset=0x7f96cc6870a8, buff=0x7f96cc686c90 "1048576", length=0x7f96cc687098) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sql_show.cc:2856
#9  0x0000000000edca62 in System_variable::init (this=0x7f96cc686c80, target_thd=0x7f96341c5ab0, show_var=0x7f9634b59070, query_scope=OPT_SESSION) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/storage/perfschema/pfs_variable.cc:537
#10 0x0000000000edd0a6 in PFS_system_variable_cache::do_materialize_all (this=this@entry=0x7f9634805838, unsafe_thd=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/storage/perfschema/pfs_variable.cc:231

...

#31 0x0000000000c563b7 in do_command (thd=thd@entry=0x7f96341c5ab0) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sql_parse.cc:1025
#32 0x0000000000d18718 in handle_connection (arg=arg@entry=0x241ab630) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/conn_handler/connection_handler_per_thread.cc:300
#33 0x0000000000eb3504 in pfs_spawn_thread (arg=0x2419a740) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/storage/perfschema/pfs.cc:2190
#34 0x00007f9c1c16d6ba in start_thread () from /libpthread.so.0
#35 0x00007f9c1b60241d in clone () from /libc.so.6

Owns:
  THD::LOCK_thd_data (acquired in PFS_system_variable_cache::do_materialize_all -> PFS_variable_cache<Var_type>::get_THD -> Find_THD_variable::operator())
Waits for:
  MYSQL_BIN_LOG::LOCK_log

...

Thread 59 (LWP 48416):
#0  0x00007f9c1c17626d in __lll_lock_wait () from /libpthread.so.0
#1  0x00007f9c1c16fdbd in pthread_mutex_lock () from /libpthread.so.0
#2  0x0000000000e38661 in native_mutex_lock (mutex=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:84
#3  my_mutex_lock (mp=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:182
#4  inline_mysql_mutex_lock (src_line=885, src_file=0x12ee750 "/build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.h", that=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/mysql/psi/mysql_thread.h:715
#5  MYSQL_BIN_LOG::lock_index (this=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.h:885
#6  show_binlogs (thd=thd@entry=0x7f95e4408a80) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/rpl_master.cc:718
#7  0x0000000000c4f163 in mysql_execute_command (thd=thd@entry=0x7f95e4408a80, first_level=first_level@entry=true) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/sql_parse.cc:3503
...

Owns:
  MYSQL_BIN_LOG::LOCK_log (acquired in show_binlogs()
Waits for:
  MYSQL_BIN_LOG::LOCK_index

,,,

Thread 30 (LWP 57186):
#0  0x00007f9c1c17626d in __lll_lock_wait () from /libpthread.so.0
#1  0x00007f9c1c16fefe in pthread_mutex_lock () from /libpthread.so.0
#2  0x0000000000e2c86e in native_mutex_lock (mutex=0x7f96341c6730) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:84
#3  my_mutex_lock (mp=0x7f96341c6730) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/thr_mutex.h:182
#4  inline_mysql_mutex_lock (src_file=0x158f3d0 "/build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc", src_line=2759, that=0x7f96341c6730) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/include/mysql/psi/mysql_thread.h:715
#5  Adjust_offset::operator() (this=0x7f96d4073220, thd=0x7f96341c5ab0) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:2759
#6  0x00000000007896cc in Do_THD::operator() (thd=<optimized out>, this=<synthetic pointer>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/mysqld_thd_manager.cc:46
#7  std::for_each<THD**, Do_THD> (__f=..., __last=0x21378b8, __first=0x2137850) at /usr/include/c++/5/bits/stl_algo.h:3767
#8  Global_THD_manager::do_for_all_thd (this=0x21377d0, func=func@entry=0x7f96d4073220) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/mysqld_thd_manager.cc:273
#9  0x0000000000e1d49d in adjust_linfo_offsets (purge_offset=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:2801
#10 MYSQL_BIN_LOG::remove_logs_from_index (this=0x1df2e60 <mysql_bin_log>, log_info=0x7f96d40732c0, need_update_threads=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:6173
#11 0x0000000000e28522 in MYSQL_BIN_LOG::purge_logs (this=this@entry=0x1df2e60 <mysql_bin_log>, to_log=to_log@entry=0x7f96d40738a0 "/var/lib/mysql/mysql-bin.003726", included=included@entry=true, need_lock_index=need_lock_index@entry=false, need_update_threads=need_update_threads@entry=true, decrease_log_space=decrease_log_space@entry=0x0, auto_purge=true) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:6290
#12 0x0000000000e28fd9 in MYSQL_BIN_LOG::purge_logs_before_date (this=0x1df2e60 <mysql_bin_log>, purge_time=<optimized out>, auto_purge=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:6754
#13 0x0000000000e2a89e in MYSQL_BIN_LOG::ordered_commit (this=this@entry=0x1df2e60 <mysql_bin_log>, thd=thd@entry=0x7f96900008c0, all=all@entry=true, skip_commit=<optimized out>) at /build/mysql-5.7-fr19a8/mysql-5.7-5.7.23/sql/binlog.cc:9660
...

Owns:
  MYSQL_BIN_LOG::LOCK_index (acquired in MYSQL_BIN_LOG::purge_logs_before_date)
Waits for:
  THD::LOCK_thd_data

So we have thread 61 waiting for thread 59, which waits for thread 30
which waits for thread 61 -- classical loop in wait-for graph.
[22 Aug 2018 7:34] MySQL Verification Team
https://bugs.mysql.com/bug.php?id=92108
[22 Aug 2018 12:05] MySQL Verification Team
Seems that the bug:

https://bugs.mysql.com/bug.php?id=92108

is a duplicate of the this one. However, there are subtle differences. Still, bug #92108 can help in reproducing this bug.
[25 Sep 2018 11:11] Margaret Fisher
Posted by developer:
 
Changelog entry added for MySQL 8.0.14 and 5.7.25:

When the system variables binlog_transaction_dependency_tracking and binlog_transaction_dependency_history_size were set or read, the types of lock that were required could result in a deadlock scenario, because the same locks were also required for working with the active binary logs. A new lock type is now used instead for access to the transaction dependency tracking system variables, so that this deadlock cannot occur.
[20 May 2020 13:42] Margaret Fisher
Posted by developer:
 
Changelog entry added for Bug #29719364 / Bug #95181 in MySQL 8.0.21 and 5.7.31:

A fix made in MySQL 8.0.14 and MySQL 5.7.25 for a deadlock scenario involving  the system variables binlog_transaction_dependency_tracking and binlog_transaction_dependency_history_size had the side effect of leaving the writeset history used for transaction dependency tracking unprotected from concurrent update. The writeset history and tracking mode are now locked correctly whenever they are accessed.