MySQL:主从复制转换错误问题
主从复制转换错误问题
我的新书《深入理解MySQL主从原理》新书上架
数位数据库专家/ACEDirector/ACE赞誉推荐,凝结数百次故障诊断经验,从主库端到从库端带你深入解析MySQL主从构架的运行原理
MySQL:MySQL客户端缓存结果导致OOM
公众号 MySQL学习 这个问题很简单,稍微看看mysql客户端的代码上下文即可 一、问题相关有返回了笛卡尔积数据,导致mysql客户端吃光了内存 这种这个mysql客户端线程将会oom导致kill。 二、问题分析对于select语句来讲,对于mysql客户端而言是交互式模式而不是batch模式。 #9 0x000000000041b2ed in cli_read_rows (mysql=0xaf476
MySQL:Analyze table导致'waiting for table flush'
官方版本测试到8.0.21依旧存在这个问题,Percona已经修复了,修复如下https://www.percona.com/blog/2018/03/27/analyze-table-is-no-longer-a-blocking-operation/ 能力有限简单记录。一、问题描述问题如下: mysql> show processlist; +----+------------
MySQL:connect_timeout参数简单记录
简单记录static bool login_connection(THD *thd) { int error; DBUG_TRACE; DBUG_PRINT("info", ("login_connection called by thread %u", thd->thread_id())); /
MySQL:简单记录信号处理
码版本:5.7.29 简单记录信号如何生效的。poll收到信号后如何中断后如何处理的,需要确认。一初始化信号处理方式,设置信号的处理的处理方式,屏蔽某些信号,并且继承到子线程(pthread_sigmask),主要屏蔽的为SIGTERM、SIGQUIT、SIGHUP、SIGTSTP四个。其他信号按照默认处理方式,但是处理前打印crash栈,handle_fatal_signal 对于sigus
MySQL:MySQL工具以及5.7mysqlbinlog|mysql速度极慢问题
公众号 MySQL学习 随便记录点 5.7.22代码 MySQL工具主要分为 交互式和非交互式 交互式就是我们平时用的交互式命令方式非交互式(batch mode)主要用于解析binlog和批量导入sql,每次都会读取1行数据到buffer如果是binlog,那么每次大约读取的原始数据为76字节,及mysqlbinlog解析出来的一行AAAAAAAAAP4AAAAAAAAAAP4AAAAAAAAAAP4AAA
MySQL:乱码问题处理流程
简单记录未做代码验证 hex(col) 返回字符集直接从database charset拿,跳过了转换,直接返回二进制,可以用于测试数据库存储的是什么字符集。(需要后期代码验证)hex(‘去’) 在client charset和connect charset设置一致的情况下,不需要转换,hex直接返回输入字符的二进制,可以用于测试终端到底是字符集。(需要后期代码验证)set name
MySQL:Innodb crash recovery一些代码
简单记录可能还理解,做个笔记,不深入: http://mysql.taobao.org/monthly/2015/06/01/ buf_dblwr_init_or_load_pages 初始化dblwr从double write中,写入到内存 Recovering partial pages from the parallel doublewrite buffer at /opt
MySQL:Innodb如何快速杀掉堵塞会话的思考
本文主要讲述MySQL 5.7.29,也会加入和8的对比 一、问题起源我们在运维MySQL的过程中,肯定多多少少遇到过Innodb row lock的问题,如果在线上遇到我们可能会看到一大片的session处于堵塞状态通常我们在show processlist中会看到如下: select for update语句处于sending data状态update/delete语句处于up
MySQL:读取my.cnf的顺序问题
一、mysql.server启动方式basedir=/opt/mysql/mysql3315 datadir=/opt/mysql/mysql3315/data 进行查找,在解析参数文件的时候会带入 -e进行解析 /opt/mysql/mysql3315/bin/my_print_defaults -e /opt/mysql/mysql3315/my.cnf mysqld server my
MySQL:RR模式下insert也可能导致查询慢
RR隔离级别,简单记录如下 1、session 1开启read viewmysql> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Databa
MySQL:一个奇怪的hang案例
一、问题来源问题来自一位朋友,如下:mysql客户端无法登陆,查看服务器负载没有发现高负载信息。通过pstack查看线程栈信息,没有发现异常信息。 二、问题诊断和解决一般来讲出现这种情况,我们会使用pstack看看新建立的线程为在什么函数上卡主了,然后很容易就能找到原因。但是出现这个问题过后,当mysql发起连接后卡主后,使用pstack查看mysqld服务端的进程,发现根本就没有线程与之进行交
MySQL:MTS和mysqldump死锁
一、问题来源这是一位客户的提供的案例如下,show processlist截图如下: 出现这种问题除非手动干预,杀掉FTWRL的session主从方可以进行。版本社区版5.7.26 二、堵塞图如果分析上面的堵塞可以画图如下: 三、关于woker线程w1和w3的等待这里我们需要重点关注参数slave_preserve_commit_order,在我将要出版的《深入理解MySQL主从原理》一
MySQL:Innodb purge线程略解
水平有限,如有错误请谅解。源码版本8.0.21。 在处理一个故障的时候怀疑大量的删除数据导致了查询比较慢,但是自己对purge线程的工作流程一直不太清楚,本文不做深入解析,只做工作流程解析,带着如下问题进行: del flag记录是否能够及时清理为什么History list length持续不为0,是否代表del flag记录没有清理purge线程触发的规则是什么 一、purg
MySQL 5.7:desc order by反向定位
定位模式为PAGE_CUR_L,反向定位,想定位到最后一行然后使用handler::ha_index_prev扫描上一行。但是5.7的代价比8.0的逆序索引高。 0x4e 0x20 为20000 mysql> desc select * from sortdescpart1 where a1=4 and a2>100 and a2
MySQL:AHI 部分代码流程说明
AHI实际上就是多个hash查找表,个数由innodb_adaptive_hash_index_parts进行控制其中的建为记录本生计算的,值为rec指针。ha_node_set_data(node, block, data);如果开启debug会记录block这个属性。注意insert如果进行大量的插入,需要大量的定位操作,而不是一次定位顺序访问。及btr_cur_search_to_nth_l
MySQL:从一个案例深入剖析InnoDB隐式锁和可见性判断
一、问题抛出最近遇到一个问题,得到栈如下(5.6.25): 出现这个问题的时候只存在一个读写事务,那就是本事务。对这里的红色部分比较感兴趣,但是这里不是所有的内容都和这个问题相关,主要还是围绕可见性判断和隐式锁判定进行,算是我的思考过程。但是对Innodb认知水平有限,如有误导请谅解。使用的源码版本5.7.29。 二、read view 简述关于read view说明的文章已经很多了,我这
MySQL:关于Wating for Slave workers to free pending events等待
一、问题来源这是一位朋友给我的一个截图,说show slave status一直处于Wating for Slave workers to free pending events状态,这个库是MTS从库,版本为5.7.25 二、关于等待我曾经在我的主从原理系列中(已经成书)解释过大部分协调线程的等待,如下: “Waiting for dependent transaction to c
MySQL:关于Bug #20939184
一、Bug描述今天遇到了这个Bug进行了一下查询,这个Bug由印风提交,修复版本为5.7.26,8.0.15如下,这个Bug触发条件还是比较苛刻: [23 Apr 2015 8:42] zhai weixiang Description: Error message is reported while executing the following statements drop ta