MGR中 relay log的gap会导致hang死吗?


最近再分析一个问题的发现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可能如下,

image.png

而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已经不连续了,

image.png

这里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的拷贝,这个前面我们分析过。

那么可以理解为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,可自行查阅


16c92fdac068a3e4b33c42a44113cd4.png

六、总结

  • 主从的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
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,142评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,298评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,068评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,081评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,099评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,071评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,990评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,832评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,274评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,488评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,649评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,378评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,979评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,625评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,643评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,545评论 2 352