information_schema.innodb_trx 查询堆栈
mysqld!cache_select_table(trx_i_s_cache_t*, i_s_table) (/Users/xiaoyu.bai/Downloads/mysql-5.7.29/storage/innobase/trx/trx0i_s.cc:1525) mysqld!trx_i_s_cache_get_rows_used(trx_i_s_cache_t*,&n
mysql中的xa
事务执行开始,先获取commit的mdl锁,然后进行2pc判断,进入prepare,commit xa if (!trn_ctx->no_2pc(trx_scope) && (trn_ctx->rw_ha_count(trx_scope) > 1))  
MySQL alter 添加列对dml影响
5.7版本很多ddl都是在线的了,允许并行的dml,允许不代表线上不会有问题,下面看下alter添加字段过程中的加锁情况,主要是mdl部分的。在open_table部分会获取两个mdl锁MDL_INTENTION_EXCLUSIVE 以及MDL_SHARED_UPGRADABLE,在执行mysql_inplace_alter_table的过程中会进行mdl锁升级,升级shared 锁成MDL_EX
ordered_commit流程梳理
ordered_commit 是比较核心的函数,包含了组提交的3个阶段,以及半同步的位置,下面是梳理的对应的流程
infimum,supremum锁二
the infimum record can be a dummy target for temporary record locks. Stores on the page infimum record the ex
MySQL checkpoint执行时机
之前的文章已经说过了在undo purge的情况下会有全量checkpoint,下面记录下其他情况checkpoint的执行时机srv_master_do_active_tasks 这个函数会定时执行checkpoint/* Make a new checkpoint */ if (cur_time % SRV_MA
MySQL 网络导致的复制报错案例
线上的一个集群,从库的io线程自动停止了,看了下错误日志2022-07-29T19:10:25.749310Z 8032277 [Note] Slave I/O thread killed while reading event for channel '' 2
MySQL rr下幻读问题分析
在mysql中,针对幻读的问题,有个争论多的,链接如下:https://gaoooyh.github.io/2021-09-28-MySQL-InnoDB-RR(%E5%8F%AF%E9%87%8D%E5%A4%8D%E8%AF%BB)%E9%9A%94%E7%A6%BB%E7%BA%A7%E5%88%AB%E8%83%BD%E5%90%A6%E8%A7%A3%E5%86%B3%E5%B9%BB%
undo truncate 导致qps下降分析
5.7 有了undo truncate功能,防止undo无限增长,这个需要配置2个undotablespace 才能生效,在truncate期间,系统的qps会drop,分析下原因在debug 环境重现undo truncate后,在日志中会看到下面的输出信息2022-07-15T03:41:26.353673Z 0 [Note] InnoDB: UNDO&
mysql8 log_status 查询pos与gtid不一致 bug解析
bug:https://bugs.mysql.com/bug.php?id=102175 102175 已经详细的介绍了mysql8 log_status 查询结果出现pos跟gtid 不匹配的情况,导致备份后设置的gtid可能不正确。下面根据bug的描述,去看下代码,熟悉下相关的代码,按步骤在分析下。主要的代码就是ordered_commit, 这部分中有binlog的组提交,flus
MySQL truncate慢影响系统qps分析
bug:https://bugs.mysql.com/bug.php?id=68184 文中提到在8.0修复,下面看下5.7版本的调用堆栈mysqld!buf_LRU_flush_or_remove_pages(unsigned long, buf_remove_t, trx_t const*) (/Users/xiaoyu.bai/Downloa
MySQL的写入数据存储过程
insert 写入数据ha_innobase::write_row方法写入数据,write_row方法中进行自增列的锁定更新构建映射的template,然后通过innodb_srv_conc_enter_innodb进入innodb,这里会判断是否会超过innodb的并发限制srv_conc_enter_innodb 方法中描述了,线程是等待还是休眠如果线程有ticket,可以直接进入,如果inn
MySQL中2个select被阻塞场景的原因
第一种情况: 执行select,慢查询,然后对表alter,被阻塞,然后其他会话执行select,被阻塞当最后的select被阻塞时,在open_table_get_mdl_lock中会去获取锁,先 try_acquire_lock_impl获取,成功返回,不成功向等待队列加个ticket,进入等待mysqld!open_table_get_mdl_lock(THD*, Ope
MySQl事务创建,开始以及提交,以及insert的提交
建事务trx_allocate_for_mysql中调用trx_create 进行创建方法中分配一个内存对象,然后初始化这个对象的值,可以看到trx->id = ut_dulint_zero;在创建的时候是设置了0,创建undo_mutex事务的提交trx_commit_for_mysql trx->op_info = "committing&quo
MySQL 大字段问题
开发规范中,一般不让使用大字段,大部分关于给出的原因有影响缓存,高并发查询的情况会打满带宽,溢出存储,查询的时候多了一次指针查找,在姜老师的书中还看到了一个原因,就是大字段的dml 会使用悲观的方式处理,这种对二叉树加x-latch,会导致并发性能的下降。姜老师的书中描述是大字段的插入,更新,删除会使用悲观操作,但是我测试的情况是针对insert没有使用悲观操作,update是使用了悲观操作upd
MySQL8.0 binlog_row_metadata
MySQL 8.0 增加了binlog_row_metadata 这个参数,将表的信息写入了binlog,这样在解析的时候可以在binlog中获取表结构。测试的过程中发现,使用mysqlbinlog解析出来的结果中,并没有列的信息。发现mysqlbinlog默认是不展示列信息的,如果需要展示,需要添加print-table-metadata=true参数。mysqlbinlog --print-t
MySQL8.0 view导致的性能问题
最近将5.7的开发测试环境升级到了8.0,开发测试同学反馈在执行ddl的时候变慢了,并反馈5.7 是正常的,要看下原因,所以对8.0的代码进行下分析,期间走了很多弯路,浪费了不少的时间。在这里介绍下正确的分析问题思路。首先对alter的语句执行流程不清楚,所以也不清楚在哪里打断点,如果从一开始断电debug,无疑会浪费很多时间。所以正确的思路是使用mysql的trace功能,将sql 的执行过程全
MySQL 锁
mysql 锁研究
MySQL client server 协议
之前也是看过官方文档上面关于client server协议的介绍,总是感觉比较晦涩,看过不久就会忘记,所以写了代码验证理解下。之前写过系统表空间文件解析,感觉通讯协议跟数据存储的解析差不多,都是通过规定的方式将字节数组转化成对应的数据。测试代码中做了很大的简化,数据都是采用的最简单的,数据也都是一个包内。代码链接如下。
raft 高可用尝试
之前写的一些平台基本都是单实例的,也没考虑集群,扩展性,高可用方面。最近在测试,使用raft,实现高可用,测试了下,感觉使用没有很复杂,后面的一些系统设计开发,需要更多尝试raft。raft集群中,每个raft实例都有自己的存储,为了维护一致性,涉及到数据变更的操作,要写入log,每个实例进行应用,维护数据一致性。针对只能是leader节点的操作,需要判断当前节点是否是leader,如果不是,直接