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
MySQL:5.7.11 超过最大打开文件数crash原因解析
一、问题重现版本5.7.11,我们首先设置参数: max_connections = 20 table_open_cache = 20table_definition_cache=10 open_files_limit=300innodb_open_files=300OS中设置 hard nofile 300 soft nofile 300 这样重启后我们的数据库中ope
MySQL:8.0.21版本特性
一、新特性Mysql和Innodb增强: 1、undo可以新增表空间 mysql> CREATE UNDO TABLESPACE undo_3 ADD DATAFILE ‘file_name.ibu’; Query OK, 0 rows affected (0.11 sec) ALTER UNDO TABLESPACE innodb_undo_001 set INACTI
MySQL:为什么lsof会看到这么多临时文件
版本:5.7.29 一、问题提出一般情况下我们会使用lsof命令来查看MySQL当前使用的临时文件的使用,这是因为这些临时文件使用ls命令并不能显示,在5.7中其建立方式是使用Liunx api mkstemp进行的建立,这种文件是进程专用的,返回文件描述符后会使用api unlink进行删除。源码主要就是这一段,其包含在create_temp_file函数中。 org_fil
MySQL:MGR修改max_binlog_cache_size参数导致异常
一、问题来源这是一位朋友的问题,因为前期朋友设置max_binlog_cache_size为8m,后面在线进行了修改了本参数,但是结果导致整个3节点的MGR集群除了primary节点其他两个second节点均掉线。大概的日志如下: 二、使用binlog cache的大概流程这也是我以前写过的一个过程。 开启读写事务。执行‘DML’语句,在‘DML’语句第一次执行的时候会分配内存空间给bin
MySQL:一段innodb buffer instance和cleaner线程计算逻辑
计算逻辑位于函数innobase_start_or_create_for_mysql中 if (srv_buf_pool_instances == srv_buf_pool_instances_default) { #if defined(_WIN32) && !defined(_WIN64) /* Do not allocate to
MySQL:网络断开后执行的事务怎么处理(read_timeout/write_timeout))
水平有限,可能有误 一、read_timeout/write_timeout参数实现另外一篇关于wait_timeout的文章MySQL:参数wait_timeout和interactive_timeout以及空闲超时的实现 MySQL普通的链接没有保活机制,即没有设置socket属性,也没有设置心跳。如果网络链接断开不能及时服务端不能及时探测到。默认TCP 2小时+11次*75秒。 连
MySQL:MySQL层比较函数调用
一、问题来源最近遇到一个日期比较的问题如下: root@localhost:test:10:25:48>select from_unixtime(1596680255); +---------------------------+ | from_unixtime(1596680255) | +---------------------------+ | 2020-08-06 1
MySQL:MySQL层比较函数调用
一、问题来源最近遇到一个日期比较的问题如下: root@localhost:test:10:25:48>select from_unixtime(1596680255); +---------------------------+ | from_unixtime(1596680255) | +---------------------------+ | 2020-08-06 1
MySQL:如何对待分布偏移的数据
作者微信:gp_22389860 btr_estimate_n_rows_in_range_low 函数用于非唯一访问的行数评估也就是在执行计划生成阶段会去访问实际的数据,尽可能的得到正确的执行计划,这个过程叫做dive。其和参数eq_range_index_dive_limit有关,如果参数设置1那么将禁用dive功能,使用统计数据进行执行计划的生成。但某些时候MySQL 5.7根
MySQL:Innodb中数字的存储方式
一、问题来源如果我们查看show egnine innodb查看锁记录的时候往往会看到Innodb的数字使用类似80000001的形式显示如下: Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0 0: len 1; hex 31; asc 1;; 1: len 1; hex
MySQL:一个特殊的问题
---这是开发问的一个问题---###一、问题描述如果一个表有一个联合索引 (a,b):索引记录如下:id1 id2 1 10 1 10 1 10 2 20 2 20 3 30 3&nb
MySQL:2020 端午节随笔(索引下探和唯一索引特殊执行计划)
###一、索引数据下探http://blog.itpub.net/7728585/viewspace-2660796//* Get the number of rows in the range. This is done by calling records_in_range() unless: &nbs
MySQL:双主单写 主库偶尔出现大量延迟的原因
版本:5.7.29 水平有限有误请谅解一、问题来源这是来自我们小米消金线上数据库的一个问题。我们是双主单写,这里约定写入的库为主库,没有写入的库为从库。我们的falcon偶尔会进行报警如下(频率很低): 这是非常奇怪的,按理说我是单写的从库没有做任何操作(除了应用Event以外),主库哪来的延迟,并且延迟这么大。在我映像中有朋友问过这个问题,当时没有细细研究。 二、延迟计算的规则我们
MySQL:非叶子节点指针
这个指针为8字节:4(唯一定位字段个数)+4(page no)。函数为dict_index_build_node_ptr。仅此记录,后续研究 /**********************************************************************//** Builds a node pointer out of a physical record and
MySQL:RR模式下死锁一列
环境:版本5.7.29 RR隔离级别一、案例模拟CREATE TABLE `t8` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `d_id` varchar(40) NOT NULL DEFAULT '', `b_id` varchar(40) NOT NULL DEFAULT '', `is_dropped` tinyint(
MySQL:关于RR模式下insert..selcet sending data状态说明
一、案例由来最近看到有人在问如下: 其中的sending data是什么意思。隔离级别为RR,语句为insert..select。 二、关于sending data以前就说过这个问题,实际上sending data可能包含如下: Innodb 层数据的定位返回给MySQL 层Innodb 层数据的查询返回给MySQL 层Innodb 层数据的修改(如果是insert..select)In
MySQL:ERROR 1286 (42000): Unknown storage engine 'MyISAM'
一、错误演示如下: root@localhost:test:09:49:03>create table ttt(id int) engine=myisam ; ERROR 1286 (42000): Unknown storage engine 'MyISAM' 二、相关参数 enforce_storage_engine:建表进行引擎检查,是否满足设置的引擎值。sql_mode(NO
MySQL:关于ICP特性的说明(未完)
ICP特性是我们DBA在实际的SQL优化过程中经常能够遇到的,但是某些出现ICP的地方看起来并不那么直观,为我们产生了一定的困扰。本文通过MySQL 5.7.22 和Innodb引擎来解释一下各种情况下ICP到底下推了什么条件到引擎层。 一、ICP简述ICP:全称为Index Condition Pushdown,是MySQL 5.6引入的一项优化策略。简单的来说就是将本该在MySQL进行过