最近再分析一个问题的发现relay log中的last_commit和seq_number可能出现gap,当然这个gap的理解不是我们常说的gtid的gap,下面描述上面叫做last_commit和seq_number的gap和出现的原因。
一、last_commit和seq_number的gap现象
gap这个名字并不是我取的,而是官方取的,我们来看下面一段描述,
This test proves that sequence number gap is not generated when certification garbage collector runs during relay log rotation.
这里明显提到了sequence number gap,那么这个gap是什么意思呢,一般来讲我们的seq_number在binlog中是连续的,而last_commit始终是小于它的比如,writeset 下面的last commit和seq number可能如下,
而last commit越小可能在从库的并法度越高,可以理解为,
- 如果last commit小于等于current_lwm表示可以进行并行回放,继续。
- 如果last commit大于current_lwm则表示不能进行并行回放,需要等待。
而current_lwm就是上一组执行的事物中连续执行完成的某个seq number,当然如果有上一组有大事务,则可能导致本事务的并发不能分发event,造成堵塞,代码很简单就是如下,
Mts_submode_logical_clock::wait_for_last_committed_trx:
...
do {
mysql_cond_wait(&rli->logical_clock_cond, &rli->mts_gaq_LOCK);
} while ((!rli->info_thd->killed && !is_error) &&
!clock_leq(last_committed_arg, estimate_lwm_timestamp()));
而出现这种等待出现的信息为,“Waiting for dependent transaction to commit”。但是我们来看看一种特殊的情况,如下的last commit和seq number出现了大量的gap,也就是seq number已经不连续了,
这里seq number 从1584调到了1603然后到了1624,并且明显的看到last commit居然比上一个事务的seq number要大很多, 那这是为什么呢?会对从库的并发有影响吗?
二、主从中的last commit和seq number
实际上我们上面的描述的就是主从中last commit和seq number,seq number基于一个全局计数器生成,每次事务都会修改自增,而last commit则根据上次连续提交的最后一个事务的seq number生成(order commit)然后访问writeset(开启writeset的情况) 缓存再次降低,因此last commit是不可能大于上一个事务提交事务的seq number的。
。并且在binlog做切换的时候会记录一个offset,如下,
void Commit_order_trx_dependency_tracker::rotate() {
m_max_committed_transaction.update_offset(
m_transaction_counter.get_timestamp());
m_transaction_counter.update_offset(m_transaction_counter.get_timestamp());
}
虽然计数器一直在增大,但是每次binlog切换都记录了offset,因此在获取last commit和seq number的时候只要减去这个计数器,那么每个binlog里面的seq number和last commit又重新开始了,如下,
Commit_order_trx_dependency_tracker::get_dependency(THD *thd, binlog_prepare
int64 &sequence_number,
int64 &commit_parent)
{
..
sequence_number=
trn_ctx->sequence_number - m_max_committed_transaction.get_offset(); //这里获取seq number
commit_parent=
trn_ctx->last_committed <= m_max_committed_transaction.get_offset()
? SEQ_UNINIT
: trn_ctx->last_committed - m_max_committed_transaction.get_offset(); //这里获取last commit
}
而从库的relay log完全来自于binlog,因此其seq numer也是连续的。
三、MGR中的last commit和seq number
到了MGR 的applier通道relay log里面GTID event的生成完全不同了,当然last commit和seq number也不是一个逻辑了,更不可能是主库binlog的拷贝,这个前面我们分析过。
- MySQL:MGR(单主)备节点MTS并发原理:https://www.jianshu.com/p/fa42b04ba915
那么可以理解为gtid和last comit和seq number都是在备节点认证的时候自己生成的,而不是来自于主库。其主要抬升seq number和last commit的函数为increment_parallel_applier_sequence_number,主要有两个:
- 每次事务过认证部分的时候,seq number+1,但是这个时候last commit一般不改变,除非是DDL或者create table as这种语句是不能并发的,因此必须要抬升last commit为当前事务的seq number。
increment_parallel_applier_sequence_number( //8038本处修复BUG
!has_write_set || update_parallel_applier_last_committed_global); //增加seq number计数器
- 如果每60秒左右接受到各个节点broadcast线程发送的GTID信息后,根据全部节点执行的GITD信息,清理了冲突验证数据库无条件抬升last commit,并且并且seq number+1,这里是因为冲突验证数据库充当了writeset hitory的角色,用于降低last commit。
increment_parallel_applier_sequence_number(true);
那么这里就出现了一个疑惑,实际上每60秒不管你是否有事务,内部的seq number和last commit都会改变,等到事务来的时候就会这种gap。也就是前面截图的gap。测试的话可以自己等待120秒以上做一个事务看看seq number和last commit是否异常。比如,
insert;sleep(180);insert;
四、这种gap影响MTS并发吗?
对于MTS的并发,我们以前的讨论的是如下:
- 如果last commit小于等于current_lwm表示可以进行并行回放,继续。
如果出现这种gap,last commit已经远远大于了current_lwm(可以简单理解为上一个事务的seq number,当然这是连续事务执行完成的最后一个事务,因为可能有大事物存在),那么这里是不可能能够分发了。但是为了处理这种gap,在代码中出现了额外的控制如下,
if (unlikely(sequence_number > last_sequence_number + 1)) { //如果出现了gap MGR很容易出现GAP
..
gap_successor = true;//设置为true
一旦gap_successor 设置为true,就不是上面的last commit判断的理论了,走如下代码分支
is_new_group =
(...
/*
When gap successor depends on a gap before it the scheduler has
to serialize this transaction execution with previously
scheduled ones. Below for simplicity it's assumed that such
gap-dependency is always the case.
*/
gap_successor ||
..);
/*
The coordinator waits till all transactions on which the current one
depends on are applied.
*/
if (!is_new_group) { //这里走的分支不会在判断last commit了
...
if (wait_for_last_committed_trx(rli, last_committed))//根据last commit判断是否可以分发事务
...
}else {
...
if (-1 == wait_for_workers_to_finish(rli)) return ER_MTS_INCONSISTENT_DATA;//等待全部前置事务提交完成,完成前不分发
...}
这里大概我们可以看到最后走的wait_for_last_committed_trx函数进行等待,也就是等待前置事务全部执行完成,这个事务才可以分发,而不受last commit的影响,其等待为,"Waiting for slave workers to process their queues",因此"Waiting for slave workers to process their queues"就有了两层含义:
- 由于没有空闲的工作线程,协调线程会等待(这是以前的结论)。
- MGR下出现了gap,等待前置事务全部提交。
因此这种gap对MTS的并发影响似乎并不大,至少不是我当初想的协调线程会在“Waiting for dependent transaction to commit”状态下无限期的等待下去。
五、修复版本
在8038和8402,修复了这个BUG,可自行查阅
六、总结
- 主从的seq number一般是比较连续的,last commit依据主库的规则生成,从库的relay是binlog的完全拷贝,因此MTS并发就依赖主库生成的last commit和seq number。
- MGR 中备库的seq number和last commit是自己生成的,不仅如此gtid也是自己生成,每60秒(broadcast发送本节点gtid周期)左右会提升一次last commit和seq number,可能导致一些gap。
- MTS并发中对这种gap有控制,并不依赖last commit来进行并发,而是等待前置事务全部提交,才开始分发,因此影响并不大。
- 等待前置事务分发完成期间状态为Waiting for slave workers to process their queues。
- 8038和8402修复了这种情况。
七、备用栈等信息
本处为自备查询用
#0 Mts_submode_logical_clock::schedule_next_event (this=0x7fff8000bcd0, rli=0xafaae50, ev=0x7fff80164720) at /pxc/mysql-8.0.36/sql/rpl_mta_submode.cc:575
#1 0x00000000044db07d in schedule_next_event (ev=0x7fff80164720, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/log_event.cc:2537
#2 0x00000000044db763 in Log_event::get_slave_worker (this=0x7fff80164720, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/log_event.cc:2685
#3 0x00000000044ddc1a in Log_event::apply_event (this=0x7fff80164720, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/log_event.cc:3264
#4 0x00000000045ec51d in apply_event_and_update_pos (ptr_ev=0x7fff5c5ce038, thd=0x7fff80006540, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:4535
#5 0x00000000045edfed in exec_relay_log_event (thd=0x7fff80006540, rli=0xafaae50, applier_reader=0x7fff5c5ce170, in=0x7fff80164720) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:5034
#6 0x00000000045f6890 in handle_slave_sql (arg=0xad56e50) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:7292
#7 0x000000000518ad94 in pfs_spawn_thread (arg=0x7fff70027520) at /pxc/mysql-8.0.36/storage/perfschema/pfs.cc:3042
#8 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#9 0x00007ffff6370b0d in clone () from /lib64/libc.so.6
#0 Mts_submode_logical_clock::get_least_occupied_worker (this=0x7fff8000bcd0, rli=0xafaae50, ws=0xafad2a8, ev=0x7fff801dac60) at /pxc/mysql-8.0.36/sql/rpl_mta_submode.cc:853
#1 0x00000000044db9f8 in Log_event::get_slave_worker (this=0x7fff801dac60, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/log_event.cc:2725
#2 0x00000000044ddc1a in Log_event::apply_event (this=0x7fff801dac60, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/log_event.cc:3264
#3 0x00000000045ec51d in apply_event_and_update_pos (ptr_ev=0x7fff5c5ce038, thd=0x7fff80006540, rli=0xafaae50) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:4535
#4 0x00000000045edfed in exec_relay_log_event (thd=0x7fff80006540, rli=0xafaae50, applier_reader=0x7fff5c5ce170, in=0x7fff801dac60) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:5034
#5 0x00000000045f6890 in handle_slave_sql (arg=0xad56e50) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:7292
#6 0x000000000518ad94 in pfs_spawn_thread (arg=0x7fff70027520) at /pxc/mysql-8.0.36/storage/perfschema/pfs.cc:3042
#7 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007ffff6370b0d in clone () from /lib64/libc.so.6
#0 0x00007ffff7bcade2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x000000000492311d in native_cond_timedwait (cond=0xafab268, mutex=0xad5fe18, abstime=0x7fff5c5f3fa0) at /pxc/mysql-8.0.36/include/thr_cond.h:99
#2 0x0000000004923488 in safe_cond_timedwait (cond=0xafab268, mp=0xad5fdf0, abstime=0x7fff5c5f3fa0, file=0x6594848 "/pxc/mysql-8.0.36/sql/binlog.cc", line=7752)
at /pxc/mysql-8.0.36/mysys/thr_cond.cc:113
#3 0x000000000449bb69 in my_cond_timedwait (cond=0xafab268, mp=0xafab208, abstime=0x7fff5c5f3fa0, file=0x6594848 "/pxc/mysql-8.0.36/sql/binlog.cc", line=7752)
at /pxc/mysql-8.0.36/include/thr_cond.h:146
#4 0x000000000449bd88 in inline_mysql_cond_timedwait (that=0xafab268, mutex=0xafab208, abstime=0x7fff5c5f3fa0, src_file=0x6594848 "/pxc/mysql-8.0.36/sql/binlog.cc", src_line=7752)
at /pxc/mysql-8.0.36/include/mysql/psi/mysql_cond.h:224
#5 0x00000000044b0aff in MYSQL_BIN_LOG::wait_for_update (this=0xafaadd8, timeout=...) at /pxc/mysql-8.0.36/sql/binlog.cc:7752
#6 0x0000000004612f58 in Rpl_applier_reader::wait_for_new_event (this=0x7fff5c5f4170) at /pxc/mysql-8.0.36/sql/rpl_applier_reader.cc:300
#7 0x000000000461293f in Rpl_applier_reader::read_next_event (this=0x7fff5c5f4170) at /pxc/mysql-8.0.36/sql/rpl_applier_reader.cc:227
#8 0x00000000045f67d1 in handle_slave_sql (arg=0xada3b20) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:7278
#9 0x000000000518ad94 in pfs_spawn_thread (arg=0x7fff70028060) at /pxc/mysql-8.0.36/storage/perfschema/pfs.cc:3042
#10 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff6370b0d in clone () from /lib64/libc.so.6
handle_slave_sql
->Rpl_applier_reader::read_next_event 7278
读取下一个event 等待在这里
->exec_relay_log_event 7292
->apply_event_and_update_pos
->Log_event::apply_event
->Log_event::get_slave_worker
->schedule_next_event
-> Mts_submode_logical_clock::schedule_next_event
->Mts_submode_logical_clock::wait_for_workers_to_finish
->Mts_submode_logical_clock::wait_for_last_committed_trx
->Mts_submode_logical_clock::get_least_occupied_worker
Waiting for replica workers to process their queues
#0 0x00007ffff7bcde9d in nanosleep () from /lib64/libpthread.so.0
#1 0x00000000031d7718 in std::this_thread::sleep_for<long, std::ratio<1l, 1000000l> > (__rtime=...) at /opt/rh/devtoolset-11/root/usr/include/c++/11/bits/this_thread_sleep.h:82
#2 0x00000000031d2f78 in my_sleep (m_seconds=5) at /pxc/mysql-8.0.36/include/my_systime.h:64
#3 0x00000000045f3743 in mta_checkpoint_routine (rli=0xafaa750, force=true) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:6487
#4 0x000000000462bf67 in Mts_submode_logical_clock::wait_for_workers_to_finish (this=0x7fff7400bcd0, rli=0xafaa750, ignore=0x0) at /pxc/mysql-8.0.36/sql/rpl_mta_submode.cc:984
#5 0x000000000462b1e9 in Mts_submode_logical_clock::schedule_next_event (this=0x7fff7400bcd0, rli=0xafaa750, ev=0x7fff7402ae90) at /pxc/mysql-8.0.36/sql/rpl_mta_submode.cc:735
#6 0x00000000044db07d in schedule_next_event (ev=0x7fff7402ae90, rli=0xafaa750) at /pxc/mysql-8.0.36/sql/log_event.cc:2537
#7 0x00000000044db763 in Log_event::get_slave_worker (this=0x7fff7402ae90, rli=0xafaa750) at /pxc/mysql-8.0.36/sql/log_event.cc:2685
#8 0x00000000044ddc1a in Log_event::apply_event (this=0x7fff7402ae90, rli=0xafaa750) at /pxc/mysql-8.0.36/sql/log_event.cc:3264
#9 0x00000000045ec557 in apply_event_and_update_pos (ptr_ev=0x7fff5c5ce038, thd=0x7fff74006540, rli=0xafaa750) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:4535
#10 0x00000000045ee027 in exec_relay_log_event (thd=0x7fff74006540, rli=0xafaa750, applier_reader=0x7fff5c5ce170, in=0x7fff7402ae90) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:5034
#11 0x00000000045f68ca in handle_slave_sql (arg=0xadb7b20) at /pxc/mysql-8.0.36/sql/rpl_replica.cc:7292
#12 0x000000000518adce in pfs_spawn_thread (arg=0x7fff68028010) at /pxc/mysql-8.0.36/storage/perfschema/pfs.cc:3042
#13 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff6370b0d in clone () from /lib64/libc.so.6
以下结论是错误的,因为有控制 Mts_submode_logical_clock::schedule_next_event ,出现的等待不一样,为
Waiting for slave workers to process their queues
Mts_submode_logical_clock::wait_for_workers_to_finish
这个再MGR中特别容易出现
if (unlikely(sequence_number > last_sequence_number + 1)) { //如果出现了gap MGR很容易出现GAP
/*
TODO: account autopositioning
DBUG_ASSERT(rli->replicate_same_server_id);
*/
DBUG_PRINT("info", ("sequence_number gap found, "
"last_sequence_number %lld, sequence_number %lld",
last_sequence_number, sequence_number));
gap_successor = true;
}
}
1、大事物60秒内无法完成,这会导致broadcast线程在提升last commit期间,MTS GAP队列有等待的队列
2、60秒后 last commit和seq number 自动提升
3、回放判断后,即便大事物结束可能协调线程也无法分配事务了
简单来讲在MGR下面可能出现下面这种情况,出现last commit会调动,比如
last seqnu
1, 2
2, 3
3, 4 --->如果这个事务比较大
可能某一时间跳动为(4,5/5 ,6/6,7)
7, 8
这种情况下这个7,8这个事务就只能等待,当3,4这个事务做完了过后,也不可能满足等待 7<=4 ,这尼玛永远都不可能。(这个结论不对)
----- binlog切换的rotate event flush binary logs触发
mysql_bin_log.rotate_and_purge
->MYSQL_BIN_LOG::rotate
->MYSQL_BIN_LOG::new_file_without_locking
主库写入rotate event
#0 Rotate_log_event::write (this=0x7fff3813de10, file=0x2dc0d28 <mysql_bin_log+840>) at /opt/percona-server-locks-detail-5.7.22/sql/log_event.cc:6785
#1 0x000000000181178d in MYSQL_BIN_LOG::write_to_file (this=0x2dc09e0 <mysql_bin_log>, event=0x7fff3813de70) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:7073
#2 0x0000000001811c41 in MYSQL_BIN_LOG::new_file_impl (this=0x2dc09e0 <mysql_bin_log>, need_lock_log=false, extra_description_event=0x0)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:7199
#3 0x00000000018117df in MYSQL_BIN_LOG::new_file_without_locking (this=0x2dc09e0 <mysql_bin_log>, extra_description_event=0x0) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:7099
#4 0x0000000001813667 in MYSQL_BIN_LOG::rotate (this=0x2dc09e0 <mysql_bin_log>, force_rotate=true, check_purge=0x7fff3813e29b) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:7775
#5 0x0000000001813855 in MYSQL_BIN_LOG::rotate_and_purge (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffee400e960, force_rotate=true) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:7846
#6 0x00000000015afc5f in reload_acl_and_cache (thd=0x7ffee400e960, options=1024, tables=0x0, write_to_binlog=0x7fff3813f05c) at /opt/percona-server-locks-detail-5.7.22/sql/sql_reload.cc:160
#7 0x000000000156df3c in mysql_execute_command (thd=0x7ffee400e960, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:4433
#8 0x0000000001571bed in mysql_parse (thd=0x7ffee400e960, parser_state=0x7fff3813f5b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#9 0x000000000156673d in dispatch_command (thd=0x7ffee400e960, com_data=0x7fff3813fd90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#10 0x00000000015655c5 in do_command (thd=0x7ffee400e960) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#11 0x00000000016a635c in handle_connection (arg=0x5d18d80) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#12 0x00000000018ce0f6 in pfs_spawn_thread (arg=0x654f370) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#13 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007ffff66008dd in clone () from /lib64/libc.so.6
从库
process_io_rotate,这个地方需要处理2此因为有新老format 所以会导致从库建立2个relay log,注意从库的Rotate_log_event是IO线程进行处理的。
Breakpoint 3, process_io_rotate (mi=0x6ceeaa0, rev=0x6dcd9f0) at /opt/mysql-5.7.40/sql/rpl_slave.cc:7867
7867 DBUG_ENTER("process_io_rotate");
(gdb) bt
#0 process_io_rotate (mi=0x6ceeaa0, rev=0x6dcd9f0) at /opt/mysql-5.7.40/sql/rpl_slave.cc:7867
#1 0x0000000001812d9a in queue_binlog_ver_3_event (mi=0x6ceeaa0, buf=0x6d94d51 "", event_len=45) at /opt/mysql-5.7.40/sql/rpl_slave.cc:8067
#2 0x0000000001812feb in queue_old_event (mi=0x6ceeaa0, buf=0x6d94d51 "", event_len=45) at /opt/mysql-5.7.40/sql/rpl_slave.cc:8116
#3 0x0000000001813751 in queue_event (mi=0x6ceeaa0, buf=0x6d94d51 "", event_len=45) at /opt/mysql-5.7.40/sql/rpl_slave.cc:8313
#4 0x000000000180c728 in handle_slave_io (arg=0x6ceeaa0) at /opt/mysql-5.7.40/sql/rpl_slave.cc:5911
#5 0x0000000001ce8ce0 in pfs_spawn_thread (arg=0x6cd37d0) at /opt/mysql-5.7.40/storage/perfschema/pfs.cc:2197
#6 0x00007ffff7bbb764 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7 0x00007ffff60ade2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--- 主从last commit和seq number 清空
GTID 中last commit和seq number的来源
Transaction_dependency_tracker::get_dependency
Commit_order_trx_dependency_tracker::get_dependency(THD *thd, binlog_prepare
int64 &sequence_number,
int64 &commit_parent)
{
Transaction_ctx *trn_ctx= thd->get_transaction();
DBUG_ASSERT(trn_ctx->sequence_number
> m_max_committed_transaction.get_offset());
/*
Prepare sequence_number and commit_parent relative to the current
binlog. This is done by subtracting the binlog's clock offset
from the values.
A transaction that commits after the binlog is rotated, can have a
commit parent in the previous binlog. In this case, subtracting
the offset from the sequence number results in a negative
number. The commit parent dependency gets lost in such
case. Therefore, we log the value SEQ_UNINIT in this case.
*/
sequence_number=
trn_ctx->sequence_number - m_max_committed_transaction.get_offset(); //这里获取seq number
commit_parent=
trn_ctx->last_committed <= m_max_committed_transaction.get_offset()
? SEQ_UNINIT
: trn_ctx->last_committed - m_max_committed_transaction.get_offset(); //这里获取last commit
}
Commit_order_trx_dependency_tracker::rotate 更新offset
#0 Gtid_log_event::Gtid_log_event (this=0x7fff3813cc80, thd_arg=0x7ffee400e960, using_trans=true, last_committed_arg=0, sequence_number_arg=1, may_have_sbr_stmts_arg=false)
at /opt/percona-server-locks-detail-5.7.22/sql/log_event.cc:13661
#1 0x000000000180498b in MYSQL_BIN_LOG::write_gtid (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffee400e960, cache_data=0x7ffee4018558, writer=0x7fff3813ceb0)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:1483
#2 0x00000000018053b0 in binlog_cache_data::flush (this=0x7ffee4018558, thd=0x7ffee400e960, bytes_written=0x7fff3813cf48, wrote_xid=0x7fff3813cf87)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:1715
#3 0x0000000001820f80 in binlog_cache_mngr::flush (this=0x7ffee40183a0, thd=0x7ffee400e960, bytes_written=0x7fff3813cf88, wrote_xid=0x7fff3813cf87)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:945
#4 0x0000000001816921 in MYSQL_BIN_LOG::flush_thread_caches (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffee400e960) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:9084
#5 0x0000000001816b22 in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2dc09e0 <mysql_bin_log>, total_bytes_var=0x7fff3813d0c8, rotate_var=0x7fff3813d0c7, out_queue_var=0x7fff3813d0b8)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:9147
#6 0x0000000001818038 in MYSQL_BIN_LOG::ordered_commit (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffee400e960, all=false, skip_commit=false)
at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:9782
#7 0x0000000001816731 in MYSQL_BIN_LOG::commit (this=0x2dc09e0 <mysql_bin_log>, thd=0x7ffee400e960, all=false) at /opt/percona-server-locks-detail-5.7.22/sql/binlog.cc:9033
#8 0x0000000000f54824 in ha_commit_trans (thd=0x7ffee400e960, all=false, ignore_global_read_lock=false) at /opt/percona-server-locks-detail-5.7.22/sql/handler.cc:1830
#9 0x0000000001676337 in trans_commit_stmt (thd=0x7ffee400e960) at /opt/percona-server-locks-detail-5.7.22/sql/transaction.cc:458
#10 0x0000000001570408 in mysql_execute_command (thd=0x7ffee400e960, first_level=true) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5293
#11 0x0000000001571bed in mysql_parse (thd=0x7ffee400e960, parser_state=0x7fff3813f5b0) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:5901
#12 0x000000000156673d in dispatch_command (thd=0x7ffee400e960, com_data=0x7fff3813fd90, command=COM_QUERY) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1490
#13 0x00000000015655c5 in do_command (thd=0x7ffee400e960) at /opt/percona-server-locks-detail-5.7.22/sql/sql_parse.cc:1021
#14 0x00000000016a635c in handle_connection (arg=0x5d18d80) at /opt/percona-server-locks-detail-5.7.22/sql/conn_handler/connection_handler_per_thread.cc:312
#15 0x00000000018ce0f6 in pfs_spawn_thread (arg=0x654f370) at /opt/percona-server-locks-detail-5.7.22/storage/perfschema/pfs.cc:2190
#16 0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#17 0x00007ffff66008dd in clone () from /lib64/libc.so.6
Commit_order_trx_dependency_tracker::rotate
MGR last commit