ITPub博客

一、分发调用流程->ev->apply_event(rli); Log_event::apply_event 这里如果是非MTS进行应用 如果MTS 如果是GTID event 进行WORKER线程的分配 ，如果不是则获取WORKER线程 -> 是否是进行 MTS recovery if (rli->is_mts_recovery())

DUMP 线程启动函数调用流程 1、多次select 交互，从库需要保存主库的信息2、注册从库信息3、读取从库发送的各种信息 com_binlog_dump_gtid 读取从库的信息包括 - server id - 需要读取的binlog为名字 - 读取的位点 - 从库GTID - kill_zombie_dump_threads 杀掉本从库以前

部分栈帧： 2、prepare栈帧 (gdb) bt #0 binlog_prepare (hton=0x346f260, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:1578 #1 0x0000000000f64e80 in ha_prepare_l

关于各个Event的生成时机直接debug前面讲Event的时候给出的各个接口即可。 一、Query_log_event栈帧：初始化 #0 Query_log_event::Query_log_event (this=0x7fffec0f30d0, thd_arg=0x7ffe7c000b70, query_arg=0x22e0614 "BEGIN", query_length=5, usi

一、设置过程插入前先调用TABLE::mark_columns_per_binlog_row_image函数函数中有image的详细设置 /* Mark columns according the binlog row image option. When logging in RBR, the user can select whether to log partial

一、ONGOING_ANONYMOUS_TRANSACTION_COUNT主库 生成GTID： 这下面可以调用匿名+1 (gdb) bt #0 Gtid_state::generate_automatic_gtid (this=0x308ab20, thd=0x7ffe7c000b70, specified_sidno=0, specified_gno=0, locked_sidno=0x7

一、ONGOING_ANONYMOUS_TRANSACTION_COUNT主库 生成GTID： 这下面可以调用匿名+1 (gdb) bt #0 Gtid_state::generate_automatic_gtid (this=0x308ab20, thd=0x7ffe7c000b70, specified_sidno=0, specified_gno=0, locked_sidno=0x7

一、栈帧#0  my_delete (name=0x7ffff0fa0490 "./binlog.000005", MyFlags=0) at /root/softm/percona-server-5.7.22-22/mysys/my_delete.c:25#1  0x0000000001

Waiting for global read lock：由于flush table with read lock调用函数lock_global_read_lock导致DML操作堵塞。Waiting for commit lock ：由于flush table with read lock 调用函数make_global_read_lock_block_commit导致事务不能提交现象堵塞COMM

今天有个朋友问源码处哪里控制了sql_safe_updates的逻辑，源码如下：bool multi_delete_precheck(THD *thd, TABLE_LIST *tables) {   SELECT_LEX *select_lex= thd->lex->select_lex; &nbs

今天有个朋友问源码处哪里控制了sql_safe_updates的逻辑，源码如下：bool multi_delete_precheck(THD *thd, TABLE_LIST *tables) {   SELECT_LEX *select_lex= thd->lex->select_lex; &nbs

今天顺便看了一下，主要流程就是跟踪为什么begin后事物不会提交，最后发现在：MYSQL_BIN_LOG::commit 函数中包含这个判断if (!cache_mngr->trx_cache.is_binlog_empty() &&       ending_trans(thd, a

一、问题来源有一个朋友@水米田 问我，基于POSITION的主从。他做了如下的操作将备份的一些binlog文件加入到了目录中修改index文件，加入了这些binlog文件flush binary logs然后整个主从环境大量延迟。二、朋友的测试下面是另外一个朋友@徐晨亮的测试：master上： (root:db1@xucl:10:30:22)[(none)]> show&nbsp

简单记录如下线面3种ID到底什么意思，这个问题我一直没去看：(root@localhost)[05:47:31] [performance_schema ;]> select THREAD_ID,PROCESSLIST_ID,THREAD_OS_ID from performance_schema.threads &nbs

这是一个朋友问我的，简单记录一下一、问题我用的5.7的Mysql undo清理参数已经打开了。为什么undo tablespace没有清理。image.png二、分析这种问题应该是有大查询的存在，朋友干掉了大查询后，undo 依然没有清理。------------ TRANSACTIONS ------------ Trx id counter 33083158

这个问题是一个朋友问我的@刘加奇一、问题描述为什么我的err日志里面有大量的show engine innodb status的记录，我自己并没有开启innodb_status_output参数。二、问题分析通过查看日志，发现如下输出：2019-03-21T17:00:02.375231Z 1230497 [Warning] InnoDB: Difficul

简单记录一下，以供后面分析一、问题一个朋友@问心问我为什么在optimizing 阶段会慢mysql> show profiles;  +----------+------------+----------------------------------------+| Query_ID | Duration &nbsp

水平有限 有误请指出版本：Percona MySQL 5.7.22对于锁的学习我做了一些输出详细参考如下：https://github.com/gaopengcarl/percona-server-locks-detail-5.7.22.git其中有readme一、问题提出不知道有没有朋友和我一样用lock in share mode做加锁实验，但是却在show engine innodb sta

简单记录一下，因为看了一下Data free的计算还算准确。不是统计值大概是空闲extent的大小。ST_FIELD_INFO tables_fields_info[]= {...   {"DATA_FREE", MY_INT64_NUM_DECIMAL_DIGITS, MYSQL_TYPE_LONGLONG, 0

水平有限 有误请指出版本：Percona MySQL 5.7.22对于锁的学习我做了一些输出详细参考如下：https://github.com/gaopengcarl/percona-server-locks-detail-5.7.22.git其中有readme本文也是一个朋友问我死锁问题。@越前一、问题提出如下构造方式，问为什么RC模式下不会死锁，RR模式下死锁。drop table&