0%

简介

跳跃范围扫描是MySQL在8.0.13版本新增加的用于提高性能的新特性,跳跃范围扫描可以使以前部分无法使用到联合索引的SQL利用联合索引进行查询,并且可以更高效的利用联合索引,这对于使用MySQL联合索引进行查询的应用意义重大。

环境信息

  • MySQL版本:8.0.15
  • 操作系统版本:redhat-7.4

跳跃范围扫描

通过一个示例来解释跳跃范围扫描:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
CREATE TABLE t1 (f1 INT NOT NULL, f2 INT NOT NULL, PRIMARY KEY(f1, f2));
INSERT INTO t1 VALUES(1,1), (1,2), (1,3), (1,4), (1,5),(2,1), (2,2), (2,3), (2,4), (2,5);
INSERT INTO t1 SELECT f1, f2 + 5 FROM t1;
INSERT INTO t1 SELECT f1, f2 + 10 FROM t1;
INSERT INTO t1 SELECT f1, f2 + 20 FROM t1;
INSERT INTO t1 SELECT f1, f2 + 40 FROM t1;
ANALYZE TABLE t1;
EXPLAIN SELECT f1, f2 FROM t1 WHERE f2 > 40\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
partitions: NULL
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 53
filtered: 100.00
Extra: Using where; Using index for skip scan
1 row in set, 1 warning (0.00 sec)

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.15 |
+-----------+
1 row in set (0.00 sec)

在这个示例中,SELECT f1,f2 FROM t1 WHERE f2>40在8.0.13版本之前是通过索引全扫描的方式来获取最终的结果集,因为SELECT查询的字段全部都是索引的组成部分。MySQL通过索引全扫描获取所有的行记录,然后通过f2 > 40这个条件过滤,最终筛选出结果集返回给客户端。

众所周知,索引范围扫描的效率肯定是要高于索引全扫描的,在这个示例中,虽然查询条件是f2 > 40,属于范围查询,但是WHERE条件中不包含f1字段的的条件,所以无法使用索引范围扫描的方式过滤数据。在MySQL-8.0.13版本增加的跳跃范围扫描特性,就是针对类似的场景的优化,跳跃范围扫描在这个示例中实际是针对每一个f1字段的值,进行了范围扫描,即进行了多次范围扫描。

针对这个示例,具体的跳跃范围扫描过程如下:

  1. 获取联合索引中第一个字段f1的第一个值:f1 = 1
  2. 将获取到的值和WHERE条件中的f2的条件组合:f1 = 1 AND f2 > 40
  3. 执行这个范围扫描查询
  4. 获取联合索引中第一个字段f1的第二个值:f1 = 2
  5. 将获取到的值和WHERE条件中的f2的条件组合:f1 = 2 AND f2 > 40
  6. 执行这个范围扫描查询
  7. 将两次范围扫描查询的结果合并返回给客户端

跳跃范围扫描实际就是将一些全扫描的场景拆分成多个范围扫描,利用范围扫描的效率高于全扫描的效率,最终实现提高SQL效率。

在这个示例中,比较有跳跃范围扫描特性的SQL执行计划以及没有跳跃范围扫描特性的SQL执行计划:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# 有跳跃范围扫描特性
mysql> EXPLAIN SELECT f1, f2 FROM t1 WHERE f2 > 40\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
partitions: NULL
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 53
filtered: 100.00
Extra: Using where; Using index for skip scan
1 row in set, 1 warning (0.00 sec)

# 没有跳跃范围扫描特性
mysql> EXPLAIN SELECT f1, f2 FROM t1 WHERE f2 > 40\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
partitions: NULL
type: index
possible_keys: NULL
key: PRIMARY
key_len: 8
ref: NULL
rows: 160
filtered: 33.33
Extra: Using where; Using index
1 row in set, 1 warning (0.00 sec)

通过执行计划可以看到,有跳跃范围扫描特性的查询扫描的行数更少且过滤性更高。

使用限制以及场景

下面来说说跳跃范围扫描使用一些限制以及场景:

  • 表上至少存在一个联合索引([A_1,A_2...A_k],B_1,B_2...B_m,C,[,D_1,...,D_n]),其中A部分以及D部分可以为空,但是B和C部分不能为空。A_1,A_2..等代表字段值
  • 只针对单表查询
  • 查询中不包含GROUP BY或者DISTINCT
  • SELECT查询的字段全部被包含在索引组成部分,即符合覆盖索引规范
  • 前缀A_1,A_2...A_k部分必须是可以被相等的常量
  • 字段C上必须是一个范围条件,大于或大于等于,小于或小于等于
  • 允许在D字段上有过滤条件,但是必须和C上的范围条件一起使用

跳跃范围扫描默认是开启的,有两种方式可以关闭跳跃范围扫描特性:

  • 通过修改optimizer_switcher变量值,默认MySQL是将optimizer_switcher中的skip_scan设置为on的,可以通过将skip_scan设置为off关闭跳跃范围扫描
  • 通过Hint的方式关闭跳跃范围扫描特性:SELECT/*+ NO_SKIP_SCAN(t1 PRIMARY) */ f1, f2 FROM t1 WHERE f2 > 40;

对于使用了跳跃范围扫描特性的SQL,使用EXPLAIN查看其执行计划,可以看到:

  • 在执行计划输出的Extra一栏中有:Using index for skip scan
  • 在执行计划输出的possible_keys一栏中会显示可以使用到的索引

总结

跳跃范围扫描是对使用MySQL联合索引查询的SQL意义重大,能在使SQL查询效率更高,但是并不是使用到跳跃范围扫描就能代表SQL执行效率更高。在MySQL一些开发规范中,一般要求建立联合索引时将重复值少的字段放在联合索引前面,将重复值多的字段放在联合索引后面,方便SQL在使用联合索引时通过前面的字段快速过滤结果。但是在跳跃范围扫描特性中,是遍历前面字段的值,与后续字段的范围查询条件组合,进行范围扫描查询,那对于重复值少的字段会被拆分成多个范围扫描查询,在实际使用过程中并不一定会比索引全扫描效率更高。

所以个人觉得跳跃范围扫描适用于联合索引中前导列distinct值较少,后续字段选择过滤性又比较好的场景,能更好的发挥跳跃范围扫描的作用。

博客地址:https://win-man.github.io/
公众号:欢迎关注

写年终总结的第三年,虽然拖延症一年比一年严重,年终总结写的越来越迟,但是该总结的还是要总结的,于是就有了这篇在一片爆竹声中写下的总结。在开始写这篇总结之前看了下2016年和2017年的总结。嗯,每年年初立下的flag,都变成了狠狠的打脸。

过去

回过头看看2018年,发生了很多事情,很多事情对我打击很大,也让我重新认识了我自己劣质的本性。2018年感谢一个人进入我的生命,带给我很多,但是遗憾的是最终因为我的原因,这个人离开了我的生活。其实觉得很对不起,但是没办法回头了。时间继续走,我继续浑浑噩噩的前行着。

2018这一年,在技术上的成长,让人失望,没有开辟新的技术栈,对于原先的技术栈也没有进一步掌握。立志学Go,学K8S,结果到现在都是半桶水只能往外报名词,一点干货没有。知道要学习新的技术,知道要系统性的进行学习,知道工作之后学习需要自己挤出时间来,但是知行合一难。2018年终于对知行合一有了一个新的认识。之前是在大学中了解王阳明的时候了解到知行合一这个概念的,但是对其没有什么概念。今年突然理解了这个,知行合一最能解释“听过很多道理,但是任然过不好这一生”,个人认知和个人行为的高度统一才能将一件事情做成。2018年我从意识上都清楚的知道,多学习、多锻炼对自己好,但是行为上表现的就是沉迷于娱乐无法自拔。知易行艰。

2018这一年,在工作上承担了很多责任也承担了很多压力,有机会向上前进了一点,虽说得到这个机会的代价有点大。正好可以通过疯狂的投入到工作中去来忘记一些事情。2018年的工作中规中矩,没有特别让自己满意的地方。

2018这一年,减肥、保持健康是失败的。办了健身卡,去健身房的频率平均下来能达到每周一次,没有坚持的效果。体重奔着160去了,能感觉到自己的肚子了,每个看到的人都能说我胖了。知易行艰。

2018这一年,文章没多写,搞了个人公众号,目前苦于没有文章可以发。

2018这一年,自制力下降了,但是最近在使用FOREST这个app,目前觉得效果不错。其实这个app之前限免的时候下载过,当时的自己自制力还算可以,觉得对自己的作用不大,但是对于现在的我,这个app效果太明显了,通过苹果手机的屏幕使用时间统计,每周屏幕使用时间都以60%~80%的趋势往下降。希望能坚持住,能提升自己的自制力。

2018这一年,没有实现任何一个2017年立下的flag(逃

未来

惯例立flag,带着目的前进:

  • 把工作做好,争取升P
  • Go、k8s、SQL优化技术栈需要补全,MySQL、Linux、分布式技术栈需要加强
  • 20本书
  • 体重减到140斤
  • 多写文章,多总结
  • 想找个女朋友
  • 培养理财意识,学习理财知识

最后,但行好事,莫问前程。

博客地址:https://win-man.github.io/
公众号:欢迎关注

一、背景

1.1、需求来源

需要给客户将生产环境的数据恢复到测试环境,但是线上环境的xtrabackup全备数据量太大,拷贝下来比较麻烦,并且需要恢复的数据只有整库中的两张表的数据,所以客户只是将全备中的对应表的ibd文件以及frm文件拷贝下来了,要求根据ibd文件以及frm文件进行数据恢复。

1.2、环境介绍

  • 数据库版本:MySQL-5.7.22
  • 数据库要求:innodb_file_per_table=1

二、解决方案步骤

2.1、准备工作

  • 准备好需要进行数据恢复的表ibd文件以及frm文件
  • 安装一个新的MySQL实例
    • innodb_file_per_table
    • 安装步骤省略

2.2、表结构恢复

  • 在数据库中创建一张表名与被恢复表表名一致的表,表结构不限制

  • 将新建表的ibd文件以及frm文件拷贝到tmp目录下备份
1
# cp message_index.* /tmp/
  • 使用被恢复的frm文件替换新创建的同名表的frm文件
1
2
3
# cp /data2/message_index.frm ./
cp:是否覆盖"./message_index.frm"? y
# chown -R mysql:mysql ./*
  • 在数据库中执行show create table语句
    注意需要在show create table 查看表结构之前执行flush tables语句,因为如果message_index表之前被打开过,那么表结构会被缓存在内存中,show create table不会报错,也就无法从错误日志中拿到我们需要的信息。

  • 查看error.log,获取被恢复表的字段数
    错误日志中会打印我们需要恢复的表的字段数,这边可以看到我们需要恢复的表中含有6个字段

  • 删除message_index表,并重新创建message_index表

从上面的步骤中我们知道被恢复表中含有6个字段,所以重新创建的message_index表需要含有6个字段,字段名以及字段类型不限制

  • 再次使用被恢复的frm文件替换新创建的同名表的frm文件
1
2
3
# cp /data2/message_index.frm ./
cp:是否覆盖"./message_index.frm"? y
# chown -R mysql:mysql ./*
  • 在MySQL配置文件中添加innodb_force_recovery=6,并重启数据库

  • 通过show create table语句拿到message_index表的表结构

至此,我们就拿到了我们需要进行恢复的表的表结构。

2.3、表数据恢复

拿到表结构之后,表数据恢复步骤相对表结构恢复步骤而言会简单一些

  • 将innodb_force_recovery=6从配置文件中去掉、使用/tmp目录下的ibd文件以及frm文件覆盖当前的对应文件、重启数据库
  • 在数据库中按照获取到的表结构新建一张message_index表
  • 执行alter table discard tablespace语句
  • 1
    mysql> alter table message_index discard tablespace;

  • 将要恢复的表的ibd文件拷贝到当前库下,并更改属主以及属组

    1
    # chown -R mysql:mysql ./*
  • 执行alter table import tablespace语句

1
mysql> alter table message_index import tablespace;

可以看到数据已经都恢复回来了。

三、总结

  • 以上我们通过xtrabackup全备中的ibd文件以及frm文件恢复了数据,这样也就代表着xtrabackup就算备份失败,只要有部分ibd文件以及frm文件保证完好,MySQL也是可以进行数据恢复的,在极端情况下也能尽可能的减少损失。但是由于xtrabackup是通过记录redo日志的方式来保存备份过程中产生的增量数据,这一部分增量数据目前还没有办法恢复。
  • 导入表空间的方式,也给MySQL大数据量迁移方案提供了一种思路:直接拷贝ibd文件的方式

博客地址:https://win-man.github.io/
公众号:欢迎关注

[toc]

简介

在正常项目开发过程中,如果MySQL版本从5.6升级到5.7版本。作为DBA在考虑数据库版本升级带来的影响时,一般会有几个注意点:

  1. sql_mode 默认值的改变
  2. optimizer_switch 值的改变
  3. 备库升级影响主备复制
    本文主要内容是MySQL升级到5.7版本之后,由于默认的 sql_mode 值带来的坑以及对应的解决方案。

    案例一:ONLY_FULL_GROUP_BY

    问题描述

    MySQL版本从5.6升级至5.7之后,部分SQL执行报错,报错信息如下:
    1
    ERROR 1055 (42000): Expression #3 of XXXXXX list is not in GROUP BY clause and contains nonaggregated column ‘XXXXX.XXXXXX’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

这个问题原因在于从5.6升级至5.7版本后 sql_mode 默认值发生了改变,在5.7版本的 sql_mode 默认值中有意向 ONLY_FULL_GROUP_BY,该选项的含义表示:对于使用 GROUP BY 进行查询的SQL,不允许 SELECT 部分出现 GROUP BY 中未出现的字段,也就是 SELECT 查询的字段必须是 GROUP BY 中出现的或者使用聚合函数的或者是具有唯一属性的。

解决方案

  • 方案一(不推荐):修改5.7版本 sql_mode 值,将 ONLY_FULL_GROUP_BY 去掉
    ONLY_FULL_GROUP_BY 是加强SQL规范的,其目的是让SQL查询出来的结果更符合规范,更准确。
    如果没有 ONLY_FULL_GROUP_BY 规范限制,那么则能允许以下SQL的执行:SELECT a,b,c FROM t GROUP BY a。SQL按照a字段值进行分组,当同一个a字段值对应多个b或者c值时,查询结果中的b,c值是不确定的。
  • 方案二:对于不符合ONLY_FULL_GROUP_BY限制的字段,添加unique索引
  • 方案三:改写SQL,按照规范编写SQL
  • 方案四:使用ANY_VALUE(),对于不符合ONLY_FULL_GROUP_BY的字段使用ANY_VALUE()函数,让MySQL跳过ONLY_FULL_GROUP_BY检测
    1
    2
    3
    4
    5
    6
    mysql> SELECT name, address, MAX(age) FROM t GROUP BY name;
    ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP
    BY clause and contains nonaggregated column 'mydb.t.address' which
    is not functionally dependent on columns in GROUP BY clause; this
    is incompatible with sql_mode=only_full_group_by
    mysql>SELECT name, ANY_VALUE(address), MAX(age) FROM t GROUP BY name;

案例二:NO_ZERO_DATE & NO_ZERO_IN_DATE & time_zone

问题描述

排错阶段一

MySQL版本从5.6升级至5.7之后,创建表的过程中失败:

1
2
3
4
5
6
7
8
9
10
mysql> CREATE TABLE `t_manager` (
.....
-> `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
-> `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
-> `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
-> `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
-> `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
-> PRIMARY KEY (`CACHE_ID`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

错误提示 MODIFY_DATETIME 字段设置的默认值是无效的,考虑到刚从5.6版本升级到5.7版本,于是又去翻了翻5.7中默认的 sql_mode 值。结果发现了两个可能存在影响的选项:

  • NO_ZERO_DATE :MySQL中插入的时间字段值,不允许日期为零
  • NO_ZERO_IN_DATE :MySQL中插入的时间字段值,不允许日期和月份为零

    排错阶段二

    于是解决方案就是按照 NO_ZERO_DATE 以及 NO_ZERO_IN_DATE 的要求设置默认值,将 MODIFY_DATETIME 字段默认值设置为’1001-01-01 01:01:01’,结果发现还是无法成功创建表:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    mysql>CREATE TABLE `t_manager` (
    .....
    -> `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    -> `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
    -> `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1001-01-01 01:01:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
    -> `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
    -> `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
    -> PRIMARY KEY (`CACHE_ID`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

查看了所有的 sql_mode 值,都符合规范,但是表还是创建不成功。只好去官方手册上找找timestamp介绍:

The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of ‘1970-01-01 00:00:01’ UTC to ‘2038-01-19 03:14:07’ UTC.

排错阶段三

可以看到官方定义中timestamp字段值的范围是’1970-01-01 00:00:01’到’2038-01-19 03:14:07’,原来是我们设置的默认值不在timestamp范围之内。于是再次修改默认值:

1
2
3
4
5
6
7
8
9
10
mysql>CREATE TABLE `t_manager` (
.....
-> `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
-> `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
-> `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1970-01-01 00:00:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
-> `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
-> `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
-> PRIMARY KEY (`CACHE_ID`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

邪了门,居然还是无法成功创建表。实在是没辙了,向同事求救,同事说他在机器上试试,结果同样的语句在他的MySQL上执行成功,同样是5.7.23版本。
百思不得其解。
一气之下将两边的参数值拿出来对比了一下,果然找到了不同的根本。

测试环境 同事环境
system_time_zone=CST system_time_zone UTC
time_zone=’+08:00’ time_zone=SYSTEM

回过头来看timestamp字段定义的范围:

The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of ‘1970-01-01 00:00:01’ UTC to ‘2038-01-19 03:14:07’ UTC.

这个时间范围指的是UTC时区的时间范围,测试环境设置了CST东八区的时区,则对应的时间范围上也需要对应的加8小时。所以将timestamp字段默认值修改为’1970-01-01 08:00:01’,表终于创建成功。

1
2
3
4
5
6
7
8
9
10
mysql>CREATE TABLE `mn_cache_refresh_manager` (
......
-> `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
-> `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
-> `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1970-01-01 08:00:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
-> `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
-> `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
-> PRIMARY KEY (`CACHE_ID`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)

解决方案

  • 将timestamp字段默认值修改为对应CST时区的最小值’1970-01-01 08:00:01’

    总结

    最后总结一下MySQL中5.7中sql_mode参数默认值的几个意思
  • ONLY_FULL_GROUP_BY
    对于使用 GROUP BY 进行查询的SQL,不允许 SELECT 部分出现 GROUP BY 中未出现的字段,也就是 SELECT 查询的字段必须是 GROUP BY 中出现的或者使用聚合函数的或者是具有唯一属性的。
  • STRICT_TRANS_TABLES
    该选项针对事务性存储引擎生效,对于非事务性存储引擎无效,该选项表示开启strict sql模式。在strict sql模式下,在INSERT或者UPDATE语句中,插入或者更新了某个不符合规定的字段值,则会直接报错中断操作
  • NO_ZERO_IN_DATE
    MySQL中插入的时间字段值,不允许日期和月份为零
  • NO_ZERO_DATE
    MySQL中插入的时间字段值,不允许日期为零
  • ERROR_FOR_DIVISION_BY_ZERO
    INSERT或者UPDATE语句中,如果数据被0除,则出现警告(非strict sql模式下)或者错误(strict sql模式下)。
    • 当该选项关闭时,数字被0除,得到NULL且不会产生警告
    • 当该选项开启且处于非strict sql模式下,数字被0除,得到NULL但是会产生警告
    • 当该选项开启且处于strict sql模式下,数字被0除,产生错误且中断操作
  • NO_AUTO_CREATE_USER
    之前版本中使用GRANT语法,如果用户不存在则会自动创建用户,该选项限制该功能
  • NO_ENGINE_SUBSTITUTION
    在使用CREATE TABLE或者ALTER TABLE语法执行存储引擎的时候,如果设定的存储引擎被禁用或者未编译,会产生错误。

博客地址:https://win-man.github.io/
公众号:欢迎关注

原文地址:http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html?view=classic
原文作者: Sunny Bains, Jiamin Huang (University of Michigan)
译者:沈刚

前言

许多用户在他们的数据库环境中使用半同步复制架构以提高数据的完整性。今天我要向大家介绍一下MySQL在5.7版本中针对半同步复制增加的新特性,这个新特性进一步增强了主库和备库之间的数据完整性。

在存储引擎层提交之前等待从库ACK

正如你所知的,在半同步复制架构中,主库上的事务提交之前会等待一个从库返回ACK信号。为了进一步增加数据的完整性,新的特性将等待从库返回ACK信号的时间点提前了(相对于MySQL5.5以及MySQL5.6),新特性中主库上的事务会在存储引擎层提交之前一直等待从库返回ACK信号。

有了这个新特性之后,半同步复制可以保证:

  • 在主库crash的情况下,所有在主库上已经提交的事务已经被复制到至少一个从库上

显而易见,因为主库上的事务无法提交,除非从库返回了ACK信号(或者超时)。
这对于用户来说有两个有利点:

  • 强数据完整性,并解决了幻读的问题
  • 简化主库Crash Recovery的过程

强数据完整性解决幻读问题

在MySQL 5.5以及MySQL 5.6开启半同步复制的场景下,主库上的事务在存储引擎层提交之后,需要等待从库返回ACK信号。并且在接收到从库返回ACK信号或者等待超时才会返回给客户端一个提交结果。

存储引擎层的提交,会持久化记录并且释放这些记录上的锁。所以在存储引擎层提交之后,其余的会话可以操作并读取这些记录,即使这个会话还在等待从库返回ACK信号。这样在主库crash,从库接管主库的情况下,产生幻读的现象。

在这个新特性中,不会发生幻读。User2在第一次SELECT的时候不会获取3这个值,因为3这条记录还没有复制从库,所以并没有在存储引擎层提交。

简化主库Crash Recovery的过程

在MySQL 5.7.2之前的版本中,用户在恢复crash掉的主库的时候,需要做以下操作:

  • 手动清除并没有被复制到从库上的binlog事务
  • 手动回滚已经提交但是还没有被复制的事务

因为新的特性保证所有的事务在提交之前都至少复制到一个从库上了,所以第二步可以不用做了。

如何设置新特性

这个特性的设置很简单,用户无需任何设置,因为在MySQL 5.7.2版本之后该特性是默认开启的。用户可以设置rpl_semi_sync_master_wait_point变量控制主库等待从库返回ACK信号的时间点。

这是一个全局、可动态修改的参数。在5.7.2版本之后,该变量的默认值是AFTER_SYNC,该值表示,主库上的事务会在flush binlog之后,在存储引擎层提交之前的时间点,等待从库返回ACK信号。

你也可以将该参数设置为AFTER_COMMIT值不开启新特性,保持和之前版本一样的机制。但是我想不到一个理由让用户设置该变量为AFTER_COMMIT值。开启新特性并没有副作用,也不会对数据库性能产生影响。

Dump线程的优化

在开发这个特性的过程中,我们对Dump线程做了一些优化。我们重构了Dump线程先关的代码,但是更重要的是,在Dump线程读取binlog event的时候,Dump线程不会再去获取binlog锁。这一改进增加了主库的一个吞吐量并且减小了主从之间的延迟。

最后

总而言之,这个新特性保证了主库和从库之间的数据完整性、一致性,并不会带来任何副作用以及性能印象。我强烈推荐你去尝试该特性。

A special thanks to Mr. Zhenxing Zhou a community user who contributed a patch implementing a similar idea based on MySQL 5.5. Even though we did not take his patch (the 5.7 codebase changed quite a lot compared to 5.5), his feature request was yet another source of motivation and inspiration.

博客地址:https://win-man.github.io/
公众号:欢迎关注

MySQL8.0——Resource Group(资源组)

资源组介绍

简介

MySQL是单进程多线程的程序,MySQL线程包括后台线程(Master Thread、IO Thread、Purge Thread等),以及用户线程。在8.0之前,所有线程的优先级都是一样的,并且所有的线程的资源都是共享的。但是在MySQL8.0之后,由于Resource Group特性的引入,我们可以来通过资源组的方式修改线程的优先级以及所能使用的资源,可以指定不同的线程使用特定的资源。
在目前版本中DBA只能操控CPU资源,并且控制的最小力度为vCPU,即操作系统逻辑CPU核数(可以通过lscpu命令查看可控制CPU总数)。
DBA经常会遇到需要执行跑批任务的需求,这种跑批的SQL一般都是很复杂、运行时间长、消耗资源多的SQL。所以很多跑批任务都是在业务低峰期的时候执行,并且在从库上执行,尽可能降低对业务产生影响。但是对于一些数据一致性比较高的跑批任务,需要在主库上执行,在跑批任务运行的过程中很容易影响到其他线程的运行。那么现在Resource Group就是DBA的福音了,我们可以对跑批任务指定运行的资源组,限制任务使用的资源,减少对其他线程的影响。

资源组信息查看

  • INFORMATION_SCHEMA.RESOURCE_GROUPS

INFORMATION_SCHEMA库下的RESOURCE_GROUPS表中记录了所有定义的资源组的情况:

1
2
3
4
5
6
7
8
mysql> select * from information_schema.resource_groups;
+---------------------+---------------------+------------------------+----------+-----------------+
| RESOURCE_GROUP_NAME | RESOURCE_GROUP_TYPE | RESOURCE_GROUP_ENABLED | VCPU_IDS | THREAD_PRIORITY |
+---------------------+---------------------+------------------------+----------+-----------------+
| USR_default | USER | 1 | 0-23 | 0 |
| SYS_default | SYSTEM | 1 | 0-23 | 0 |
+---------------------+---------------------+------------------------+----------+-----------------+
2 rows in set (0.00 sec)

MySQL8.0默认会创建两个资源组,一个是USR_default另一个是SYS_default

  • PERFORMANCE_SCHEMA.THREADS

PERFORMANCE_SCHEMA库下的THREADS表中,可以查看当前线程使用资源组的情况:

1
2
3
4
5
6
7
8
9
10
11
mysql> mysql> select * from performance_schema.threads limit 5;
+-----------+------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
| THREAD_ID | NAME | TYPE | PROCESSLIST_ID | PROCESSLIST_USER | PROCESSLIST_HOST | PROCESSLIST_DB | PROCESSLIST_COMMAND | PROCESSLIST_TIME | PROCESSLIST_STATE | PROCESSLIST_INFO | PARENT_THREAD_ID | ROLE | INSTRUMENTED | HISTORY | CONNECTION_TYPE | THREAD_OS_ID | RESOURCE_GROUP |
+-----------+------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
| 1 | thread/sql/main | BACKGROUND | NULL | NULL | NULL | mysql | NULL | 96053 | NULL | NULL | NULL | NULL | YES | YES | NULL | 9130 | SYS_default |
| 3 | thread/innodb/io_ibuf_thread | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | YES | YES | NULL | 9135 | SYS_default |
| 4 | thread/innodb/io_log_thread | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | YES | YES | NULL | 9136 | SYS_default |
| 5 | thread/innodb/io_read_thread | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | YES | YES | NULL | 9138 | SYS_default |
| 6 | thread/innodb/io_read_thread | BACKGROUND | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | YES | YES | NULL | 9137 | SYS_default |
+-----------+------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
5 rows in set (0.00 sec)

其中RESOURCE_GROUP字段显示线程使用的是哪个资源组。

如何使用资源组

假设我们现在需要对跑批任务创建一个资源组。

创建一个资源组

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
mysql> CREATE RESOURCE GROUP Batch
-> TYPE = USER
-> VCPU = 2-3
-> THREAD_PRIORITY = 10;
Query OK, 0 rows affected (0.03 sec)

mysql> select * from information_schema.resource_groups;
+---------------------+---------------------+------------------------+----------+-----------------+
| RESOURCE_GROUP_NAME | RESOURCE_GROUP_TYPE | RESOURCE_GROUP_ENABLED | VCPU_IDS | THREAD_PRIORITY |
+---------------------+---------------------+------------------------+----------+-----------------+
| USR_default | USER | 1 | 0-23 | 0 |
| SYS_default | SYSTEM | 1 | 0-23 | 0 |
| Batch | USER | 1 | 2-3 | 10 |
+---------------------+---------------------+------------------------+----------+-----------------+
3 rows in set (0.00 sec)

指定使用资源组

将创建的Batch资源组绑定到执行的线程上,有两种方式:

  • 方式一
    从PERFORMANCE_SCHEMA.THREADS表中查找需要绑定执行的线程ID(注意:THREADS表中的THREAD_ID和SHOW PROCESSLIST的ID不等同):

查看需要绑定需要的线程的THREAD_ID:

1
2
3
4
5
6
7
8
mysql> select * from performance_schema.threads where TYPE='FOREGROUND';
+-----------+--------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------------------------------------------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
| THREAD_ID | NAME | TYPE | PROCESSLIST_ID | PROCESSLIST_USER | PROCESSLIST_HOST | PROCESSLIST_DB | PROCESSLIST_COMMAND | PROCESSLIST_TIME | PROCESSLIST_STATE | PROCESSLIST_INFO | PARENT_THREAD_ID | ROLE | INSTRUMENTED | HISTORY | CONNECTION_TYPE | THREAD_OS_ID | RESOURCE_GROUP |
+-----------+--------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------------------------------------------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
| 61 | thread/sql/compress_gtid_table | FOREGROUND | 5 | NULL | NULL | NULL | Daemon | 96613 | Suspending | NULL | 1 | NULL | YES | YES | NULL | 9211 | SYS_default |
| 65 | thread/sql/one_connection | FOREGROUND | 10 | root | localhost | NULL | Query | 0 | Sending data | select * from performance_schema.threads where TYPE='FOREGROUND' | NULL | NULL | YES | YES | Socket | 9741 | USR_default |
+-----------+--------------------------------+------------+----------------+------------------+------------------+----------------+---------------------+------------------+-------------------+------------------------------------------------------------------+------------------+------+--------------+---------+-----------------+--------------+----------------+
2 rows in set (0.00 sec)

绑定将线程与Batch资源组绑定:

1
SET RESOURCE GROUP Batch FOR 65;

查看绑定结果:

1
2
3
4
5
6
7
8
mysql> select THREAD_ID,NAME,TYPE,PROCESSLIST_ID,RESOURCE_GROUP from performance_schema.threads where TYPE='FOREGROUND';
+-----------+--------------------------------+------------+----------------+----------------+
| THREAD_ID | NAME | TYPE | PROCESSLIST_ID | RESOURCE_GROUP |
+-----------+--------------------------------+------------+----------------+----------------+
| 61 | thread/sql/compress_gtid_table | FOREGROUND | 5 | SYS_default |
| 65 | thread/sql/one_connection | FOREGROUND | 10 | Batch |
+-----------+--------------------------------+------------+----------------+----------------+
2 rows in set (0.00 sec)
  • 方式二

采用Optimizer Hints的方式指定SQL使用的资源组:

1
SELECT /*+ RESOURCE_GROUP(Batch) */ * FROM t2 ;

修改资源组配置

可能跑批任务使用CPU资源不够,那就需要修改资源组的配置。

1
ALTER RESOURCE GROUP Batch VCPU = 10-20;

修改资源组优先级:

1
ALTER RESOURCE GROUP Batch THREAD_PRIORITY = 5;

禁止使用资源组:

1
ALTER RESOURCE GROUP Batch DISABLE FORCE;

删除资源组

对于不用的资源组可以删除

1
DROP RESOURCE GROUP Batch;

使用注意点

  • CREATE RESOURCE GROUP、ALTER RESOURCE GROUP、DROP RESOURCE GROUP等SQL语句并不会被记录到binlog中,不会被复制到从库。
  • 如果MySQL安装了thread pool插件,无法使用RESOURCE GROUP特性
  • macOS 平台上不支持RESOURCE GROUP特性
  • FreeBSD 和 Solaris 平台上无法指定资源组优先级(priorities),所有线程运行在0状态。
  • Linux 平台上需要开启 CAP_SYS_NICE 特性才能使用RESOURCE GROUP
1
2
3
4
5
6
7
8
9
10
11
12
检查mysqld进程是否开启CAP_SYS_NICE特性
[root@qdata-sto3 /root]
#getcap /home/mysql/program/mysql8.0/bin/mysqld

给mysqld进程开启CAP_SYS_NICE特性
[root@qdata-sto3 /root]
#setcap cap_sys_nice+ep /home/mysql/program/mysql8.0/bin/mysqld

检查是否开启成功
[root@qdata-sto3 /root]
#getcap /home/mysql/program/mysql8.0/bin/mysqld
/home/mysql/program/mysql8.0/bin/mysqld = cap_sys_nice+ep
  • Windows平台上线程优先级只有5个等级,分别为THREAD_PRIORITY_HIGHEST、THREAD_PRIORITY_ABOVE_NORMAL、THREAD_PRIORITY_NORMAL、THREAD_PRIORITY_BELOW_NORMAL、THREAD_PRIORITY_LOWEST

总结

Resource Group是MySQL在8.0中增加的资源管理的特性,从一个DBA的角度,可以更加灵活、便捷的管理数据库使用的资源,这是一个令人眼前一亮的特性。Oracle在10g的时候已经推出了Resource Manager的特性,MySQL的Resource Group目前还很简单只能控制CPU的资源,但是相信后续Resource Group能操控的资源类型会越来越多。期待MySQL8.0早日成为一个成熟稳定的版本。

博客地址:https://win-man.github.io/
公众号:欢迎关注

原文地址:https://mysqlserverteam.com/contention-aware-transaction-scheduling-arriving-in-innodb-to-boost-performance/
原文作者: Sunny Bains, Jiamin Huang (University of Michigan)
译者:沈刚

什么是事务调度?

目前大多数的数据库系统都是通过锁的方式来控制并发的情况。但是对于很多数据库厂商来说,都会有一个问题:

当有多个事务同时需要获取同一把锁,那么哪个事务应该最先获得这把锁?

包括之前版本的MySQL在内,几乎所有的数据库都是通过FIFO机制来解决这个问题。简单来说,FIFO机制就是将锁分配给最先请求该锁的事务(即该事务在等待队列的最前面,除非它们与当前锁赋予的锁不兼容)。因为这种机制是实现起来简单,所以很多的数据库厂商都是通过FIFO的策略进行事务调度,没有考虑其他的调度策略。

最近一个密歇根大学的研究组织提出,这个问题背后隐藏着巨大的性能提升空间。Mozafari教授和他的学生证明了不同的锁分配策略以及事务调度策略对于数据库性能有着很大的影响。他们提出了一种称之为Contention-Aware Transaction Scheduling(CATS)的算法,使用这种算法进行事务调度相较于之前的FIFO策略,显著地减少了数据库延迟,提高了吞吐量。

Oracle MySQL官方团队和Mozafari教授以及他的学生们紧密合作,使得MySQL是第一个采用这种新技术的数据库。在MySQL 8.0.3版本之后,CATS策略作为InnoDB的默认调度算法,也就是说MySQL的使用者可以感觉到显著的性能提升,尤其是在持续高压力负载的情况下。

CATS机制原理

CATS算法是基于很简单的一个观点:不是所有的事务都是平等的,不是所有的对象都是平等的。当一个事务已经持有了多个对象的锁,当该事务请求一个新的锁的时候,该事务应该被优先分配。从另一个方面讲,解锁这样的事务有助于解锁更多的事务。因为该事务优先被分配锁能更快的结束事务,释放另外已经获取到的对象的锁。通过这种方式可以使数据库获得更高的吞吐和更低的延迟。

有一个比喻的例子:如果有一个出租车司机和一个公交车司机都在等咖啡,那么先给公交车司机做咖啡(即使公交车司机比出租车司机迟来)可能会让更多的人尽早到达他们的目的地。因为公交车上的乘客比出租车上的乘客多。这看起来似乎对出租车司机不公平,但是这种策略可以使得整个系统运行的更快,这对于系统内的每个人都是有利的。

当然,我们现在是在解决锁的问题而不是交通司机的问题。让我们通过一个简单的例子来阐述一下CATS机制在数据库中是如何工作的。我们知道在不同的事务隔离级别下,事务在读取或者更新数据的时候,需要先获取对应数据的锁。当一个事务所需要的锁已经被其他事务所持有了,那么这个事务会一直等待直到其他事务释放这个锁。当事务已经持有一部分对象锁的时候,可能会在获取其他对象的锁的时候一直被阻塞住,这个时候就需要死锁检测机制来检测当前数据库中没有锁等待循环,防止死锁。来看下面这张图:

Transaction contention
在这种场景下,FIFO策略很简单,只需要考虑那个事务先请求O1对象的锁。但是CATS算法会更加智能地处理这个情况:CATS算法会计算每个事务直接阻塞和间接阻塞的事务数量,然后将O1对象的锁分配给阻塞了更多事务的事务。在这个场景下,t1事务阻塞了4个事务,t2事务阻塞了3个事务。所以根据CATS算法会将O1对象的锁分配给t1事务。这样可以将更多的事务释放出来,这样有利于提高系统整体的性能。

对于共享锁(S锁),CATS算法会尽可能多的分配共享锁。在这方面FIFO和CATS算法有不同的地方。FIFO按照队列的先后顺序分配共享锁,当遇到分配的对象上已经有排他锁(X锁)了,则停止分配。而在CATS中,按照事务阻塞的事务数进行倒序排序,然后按照这个顺序进行锁分配。

CATS机制带来的性能提升

Oracle的Dimitri Kravtchuk通过Sysbench 的OLTP脚本测试这种新的算法。通过结果显示,在并发情况下,CATS算法比FIFO算法在TPS,平均延迟,95%延迟等指标方面都有显著的性能提升。有趣的是,即使在没有并发的情况下,CATS算法的性能和FIFO算法性能是一样的。那是因为在没有并发的时候,没有事务需要进行调度,所以也就没有性能的差异。换而言之,使用CATS算法替换FIFO算法,没有任何损失,反而在数据库繁忙的时候,有很大的性能提升。

CATS vs. FIFO in TPS, mean latency and 95th percentile (up to 5.05x improvement)

结论

MySQL是全球第一个使用这种最先进的CATS事务调度算法的数据库。这个算法解决了数据库在遇到高压力情况下性能急剧下降的问题,这个也是MySQL 8.0主要想要达到的目标。
CATS算法是针对当事务并发超过32的情况,这个数值没有参数配置,是通过经验设置的。

博客地址:https://win-man.github.io/
公众号:欢迎关注

1、简介

MySQL 8.0 将数据库元信息都存放于InnoDB存储引擎表中,在之前版本的MySQL中,数据字典不仅仅存放于特定的存储引擎表中,还存放于元数据文件、非事务性存储引擎表中。本文将会介绍MySQL 8.0对数据字典的改进,以及改进带来的好处、影响以及局限性。

2、数据字典

2.1、新版本之前的数据字典

数据字典是数据库重要的组成部分之一,那么什么是数据字典?数据字典包含哪些内容呢?数据字典是对数据库中的数据、库对象、表对象等的元信息的集合。在MySQL中,数据字典信息内容就包括表结构、数据库名或表名、字段的数据类型、视图、索引、表字段信息、存储过程、触发器等内容。MySQL INFORMATION_SCHEMA库提供了对数据局元数据、统计信息、以及有关MySQL server的访问信息(例如:数据库名或表名,字段的数据类型和访问权限等)。该库中保存的信息也可以称为MySQL的数据字典。
在MySQL8.0之前,MySQL的数据字典信息,并没有全部存放在系统数据库表中,部分数据库数据字典信息存放于文件中,其余的数据字典信息存放于数据字典库中(INFORMATION_SCHEMA,mysql,sys)。例如表结构信息存放在.frm文件中,数据库表字段信息存放于INFORMATION_SCHEMA下的COLUMNS表中。早期,5.6版本之前,MyISAM是MySQL的默认存储引擎,而作为MyISAM存储引擎,它是没有数据字典的。只有表结构信息记录在.frm文件中。MySQL5.6版本之后,将InnoDB存储引擎作为默认的存储引擎。在InnoDB存储引擎中,添加了一些数据字典文件用于存放数据字典元信息,例如:.opt文件,记录了每个库的一些基本信息,包括库的字符集等信息,.TRN.TRG文件用于存放触发器的信息内容。

2.2、新版本数据字典的改进

最新的MySQL 8.0 发布之后,对数据库数据字典方面做了较大的改进。

  • 首先是,将所有原先存放于数据字典文件中的信息,全部存放到数据库系统表中,即将之前版本的.frm,.opt,.par,.TRN,.TRG,.isl文件都移除了,不再通过文件的方式存储数据字典信息。
  • 其次是对INFORMATION_SCHEM,mysql,sys系统库中的存储引擎做了改进,原先使用MyISAM存储引擎的数据字典表都改为使用InnoDB存储引擎存放。从不支持事务的MyISAM存储引擎转变到支持事务的InnoDB存储引擎,为原子DDL的实现,提供了可能性。

3、新数据字典带来的影响

3.1、INFORMATION_SCHEMA性能提升

8.0中对数据字典进行改进之后,很大程度上提高了对INFORMATIONS_SCHEMA的查询性能,通过可以通过查表快速的获得想要查询的数据,原因是:

  • 数据库在查询INFORMATION_SCHEMA的表时,不再一定需要创建一张临时表,可以直接查询数据字典表。
  • 在之前版本中,数据字典信息不一定是存放于表中,所以在获取数据字典信息时候,不仅仅是查表操作。例如读取数据库表结构信息,底层其实是读取.frm文件来获得,是一个文件打开读取的操作。而在新版本中,数据字典信息都可以通过直接查表的方式获取,替代那些获取信息慢的方式。
  • 对存储引擎的改进之后,在查询INFORMATIONS_SCHEMA表时,如果表上有索引,优化器会合理的利用索引。
  • 对于INFORMATION_SCHEMA下的STATISTICS表和TABLES表中的信息,8.0中通过缓存的方式,以提高查询的性能。可以通过设置information_schema_stats_expiry参数设置缓存数据的过期时间,默认是86400秒。查询这两张表的数据的时候,首先是到缓存中进行查询,缓存中没有缓存数据,或者缓存数据过期了,查询会从存储引擎中获取最新的数据。如果需要获取最新的数据,可以通过设置information_schema_stats_expiry参数为0或者ANALYZE TABLE操作。

3.2、原子DDL

MySQL8.0开始支持原子DDL操作,一个原子DDL操作,具体的操作内容包括:数据字典更新,存储引擎层的操作,在binlog中记录DDL操作。并且这些操作都是原子性的,表示中间过程出现错误的时候,是可以完整回退的。这在之前版本的DDL操作中是不支持的。之前数据库版本中一直没有支持原子DDL的特性,是有原因的,因为在早期的数据库版本中,数据库元信息存放于元信息文件中、非事务性表中以及特定存储引擎的数据字典中。这些都无法保证DDL操作内容在一个事务当中,无法保证原子性。
具体的原子DDL,后续会有专门的文章。

3.3、innodb_read_only对所有存储引擎生效

在8.0之前版本中,innodb_read_only参数可以阻止对InnoDB存储引擎表的create和drop等更新操作。但是在MySQL8.0中,开启innodb_read_only参数阻止了所有存储引擎的这些操作。create或者drop表的操作都需要更新数据字典表,8.0中这个数据字典表都改为了InnoDB存储引擎,所以对于数据字典表的更新会失败,从而导致各存储引擎create和drop表失败。同样的像ANALYZE TABLEALTER TABLE tbl_name ENGINE=engine_name这种操作也会失败,因为这些操作都要去更新数据字典表。

3.4、mysqldump mysqlpump导出的内容影响

MySQL8.0之后,在使用mysqldump和mysqlpump导出数据时候,与之前有了一些不同,主要是以下几点:

  • 之前版本的mysqldump和mysqlpump可以导出mysql系统库中的所有表的内容,8.0之后,只能导出mysql系统库中的非data dictionary table。(data dictionary table内容可以参照:https://dev.mysql.com/doc/refman/8.0/en/system-database.html#system-database-data-dictionary-tables)
  • 之前版本当使用–all-databases参数导出数据的时候,不加–routines和–events选项也可以导出触发器、存储过程等信息,因为这些信息都存放于proc和event表中,导出所有表即可导出这些信息。但是在8.0中,proc表和event表都不再使用,并且定义触发器、存储过程的数据字典表不会被导出,所以在8.0中使用mysqldump、mysqlpump导出数据的时候,如果需要导出触发器、存储过程等内容,一定需要加上–routines和–events选项。
  • 之前版本中–routines选项导出的时候,备份账户需要有proc表的SELECT权限,在8.0中需要对所有表的SELECT权限
  • 之前版本中,导出触发器、存储过程可以同时导出触发器、存储过程的创建和修改的时间戳,8.0中不再支持。

    3.5、新数据字典的局限性

    MySQL8.0数据字典的改进有很多方便的特性,例如带来了原子DDL,提升了INFORMATION_SCHEMA的查询性能等,但是它并不是完美的,新版数据字典还是存在一些局限性:
  • 通过手动mkdir的方式在数据目录下创建库目录,这种方式是不会被数据库所识别到。
  • DDL操作会花费更长的时间,因为之前的DDL操作是直接对.frm文件进行更改操作,只要写一个文件,现在是需要更新数据字典表,代表着需要将数据写到存储引擎、read log、undo log中。

    4、总结

    目前已经正式GA的MySQL 8.0是令人很期待的一个版本,从数据字典方面的改进,到原子DDL,到数据库self tuning等等新特性,都让人为8.0感到激动。8.0中有许多新特性等待去尝试,去发现。

博客地址:https://win-man.github.io/
公众号:欢迎关注

1. 简介

在数据库中间件读写分离应用场景中,如何保证底层数据库出现故障节点的时,中间件可以快速断开或迁移数据库连接,让用户无感知。
在MySQL数据库中,提供了一个session_track_transaction_info参数来提供解决方案。
因为官方文档上没有对该参数的说明,本文专门介绍该参数的可选值并验证了实际的影响。

2. session_track_transaction_info参数

2.1 参数介绍

MySQL5.7中,可以通过设置session_track_transaction_info变量来跟踪事务的状态。

  • 该参数存在global以及session两个级别,可以动态修改。
  • 该参数可以设置的值为0(默认OFF),1,2
    1
    2
    3
    4
    5
    6
    7
    8
    /**
    Transaction tracking level
    */
    enum enum_session_track_transaction_info {
    TX_TRACK_NONE = 0, ///< do not send tracker items on transaction info
    TX_TRACK_STATE = 1, ///< track transaction status
    TX_TRACK_CHISTICS = 2 ///< track status and characteristics
    };

该参数允许设置的值为0,1,2

  • 设置为0的时候,show variables like '%session_track_transaction_info%'显示为OFF,表示不开启事务状态跟踪
  • 设置为1的时候,show variables like '%session_track_transaction_info%'显示为STATE,表示跟踪事务状态
  • 设置为2的时候,show variables like '%session_track_transaction_info%'显示为CHARACTERISTICS,表示跟踪事务状态和语句

2.2 参数设置影响

开启session_track_transaction_info参数的时候,在数据库中无法直接查询到事务状态记录。
根据[WL#4797],MySQL是将事务状态跟踪的信息记录到了每一个Query请求返回的OK packet中。
可以通过抓包的方式查看事务状态信息。

2.2.1 原生MySQL OK packet格式

OK Packet的数据包格式定义

类型 名字 描述
int<1> 头部 用0x00或者0xFE表示该数据包是一个OK Packet
int 影响的行数 影响的行数
int 上次插入的id 上次插入的id
int<2> 状态标识 如果定义了CLIENT_PROTOCOL_41,会有这一部分
int<2> 警告数量 警告的数量,如果定义了CLIENT_PROTOCOL_41,会有这一部分
int<2> 状态标识 如果定义了CLIENT_TRANSACTIONS,会有这一部分
string 信息 人类可读的状态信息,如果定义了CLIENT_SESSION_TRACK,会有这一部分
string 会话状态 会话状态信息,如果定义了SERVER_SESSION_STATE_CHANGED,会有这一部分
string 信息 人类可读的信息

其中int<lenenc>string<lenenc>中的lenenc表示的是LengthEcode。

MySQL-5.7.19代码中封装OK packet的代码部分在protocol_classic.cc文件中的net_send_ok()函数中。

2.2.3 session_track_transaction_info 额外补充信息

session_track_transaction_info使用8个字符位来表示事务的信息,并且这8个字符信息是保存在COM_QUERY请求语句的返回数据包中的(客户端执行一条语句,都会被封装成MySQL协议中的COM_QUERY请求发送给server端,server端解析执行之后将结果封装在数据包中返回)。

位置 表示信息 具体代表含义
Place 1 Transaction T 显式的开启一个事务
I 隐式的开启一个事务(@autocommit=0)
_ 没有活跃的事务
Place 2 unsafe read r 当前事务中读取了非事务性存储引擎的表
_ 当前事务中没有读取非事务性存储引擎的表
Place 3 transaction read R 当前事务中读取了事务性存储引擎的表
_ 当前事务中没有读取事务性存储引擎的表
Place 4 unsafe wirte w 当前事务中写入了非事务性存储引擎的表
_ 当前事务中没有写入非事务性存储引擎的表
Place 5 transaction write W 当前事务中写入了事务性存储引擎的表
_ 当前事务中没有写入事务性存储引擎的表
Place 6 unsafe statement s 当前事务中使用了不安全的语句,类似于UUID()
_ 没有使用类似的不安全的语句
Place 7 result-set S 发送给了客户端一个结果集
_ 没有结果集
Place 8 LOCKed TABLES L 表被显式的通过LOCK TABLES 语句上锁了
_ 当前事务中没有锁表

2.2.2 session_track_transaction_info = 0时OK packet格式解析

session_track_transaction_info=0表示不记录事务信息,所有在server端返回的数据包中没有事务状态跟踪信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
## session_track_transaction_info = 0
客户端执行begin;封装的数据包
06 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
62 65 67 69 6e # begin

server端返回的数据包:response
07 00 00 # playload_length
01 # sequence_id
00 # 头部 0x00表示是一个OK包
00 # 影响的行数 0
00 # 上次插入的id
03000000

客户端执行insert into t1 values(55)封装的数据包
1a 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
696e7365727420696e746f2074312076616c75657328353529 # insert into t1 values(55)

server端返回的数据包:response
07 00 00 # playload_length
01 # sequence_id
00010003000000

客户端执行commit;封装的数据包
07 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
636f6d6d6974 # commit

server端返回的数据库包:response
07 00 00 # playload_length
01 # sequence_id
00000002000000

2.2.4 session_track_transaction_info = 1时OK packet格式解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
## session_track_transaction_info = 1
客户端执行begin;封装的数据包
06 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
626567696e # begin

server端返回的数据包:response
14 00 00 # playload_length
01 # sequence_id
00 # 头部 0x00表示是一个OK包
00 # 影响的行数 0
00 # 上次插入的id
03400000000b050908
54 5f 5f 5f 5f 5f 5f 5f
# 事务状态信息 T_______
# Place 1: 54 //显式的开启一个事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 5f //当前事务中没有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表

客户端执行insert into t1 values(111)封装的数据包
1b 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
696e7365727420696e746f2074312076616c7565732831313129 # insert into t1 values(111)

server端返回的数据包:response
14 00 00 # playload_length
01 # sequence_id
00010003400000000b050908
54 5f 5f 5f 57 5f 5f 5f # 事务状态信息 T___W___
# Place 1: 54 //显式的开启一个事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 57 //当前事务中有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表

客户端执行commit;封装的数据包
07 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
636f6d6d6974 # commit

server端返回的数据包:response
1400000100000002400000000b050908
5f 5f 5f 5f 5f 5f 5f 5f # 事务状态信息________
# Place 1: 5f //没有活跃的事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 5f //当前事务中没有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表

2.2.5 session_track_transaction_info = 2时OK packet格式解析

将session_track_transaction_info参数设置为2的时候,会显示更加详细的事务状态信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
客户端执行begin;封装的数据包
06 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
626567696e # begin

server端返回的数据包:response
29 00 00 # playload_length
01 # sequence_id
000000034000000020050908
54 5f 5f 5f 5f 5f 5f 5f # 事务状态信息 T_______
0413125354415254205452414e53414354494f4e3b # START TRANSACTION;
# Place 1: 54 //显式的开启一个事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 5f //当前事务中没有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表


客户端执行 insert into t1 values(222)封装的数据包
1b 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
696e7365727420696e746f2074312076616c7565732832323229 # insert into t1 values(222)

server端返回的数据包:response
14 00 00 # playload_length
01 # sequence_id
00010003400000000b050908
54 5f 5f 5f 57 5f 5f 5f # 事务状态信息 T___W___
# Place 1: 5f //没有活跃的事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 5f //当前事务中没有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表


客户端执行commit;封装的数据包
07 00 00 # playload_length
00 # sequence_id
03 # command_type COM_QUERY
636f6d6d6974 # commit

server端返回的数据包:response
17 00 00 # playload_length
01 # sequence_id
00000002400000000e050908
5f 5f 5f 5f 5f 5f 5f 5f # 事务状态信息 ________
040100
# Place 1: 5f //没有活跃的事务
# Place 2: 5f //当前事务中没有读取非事务性存储引擎的表
# Place 3: 5f //当前事务中没有读取事务性存储引擎的表
# Place 4: 5f //当前事务中没有写入非事务性存储引擎的表
# Place 5: 5f //当前事务中没有写入事务性存储引擎的表
# Place 6: 5f //当前事务中没有使用不安全的语句
# Place 7: 5f //没有结果集
# Place 8: 5f //没有锁表

3. 总结

在设置session_track_transaction_info参数之后,在MySQL的返回数据包中可以获取到当前连接的事务状态信息。
在数据库中间件上,利用这一特性,使得MySQL故障的情况下,能够自动迁移连接,减少对用户影响。
在部分场景下能够达到底层MySQL节点故障切换了,对应用来说可以无感知的切换过去。

博客地址:https://win-man.github.io/
公众号:欢迎关注

  拖延症把这篇年终总结拖着拖着拖到了现在,想到明天就是年三十了,好像也是不得不写一下这篇年终总结,来回顾一下自己这一年,并展望新的一年?先去翻了翻去年的年终总结,貌似也是不停的拖,拖过一天是一天,快过年才写的。今年还是一样的节奏。

1. 回头看

  先翻一翻去年立下的flag,啪啪啪,脸好疼。就完成了顺利毕业以及规律作息。其他的差的很远。所以今年不立flag了,免的脸太疼。该看的书没看,改写的博客没写。今年的年终总结就是记流水账了。
  去年这一年,老子毕业了,毕业以前一直想,老子再也不想读书了,再读要成傻子了。但是真的毕业了,工作了,发现工作没有自己想象的那么舒服,有很多事情,我想的太简单。也可能是工作不顺心,导致会想一些有的没的。毕业之后还是挺怀念读书的时候的,想到之后再也没有机会那么多人聚在一个教室里,老师在上面讲课,我们在下面玩手机、聊天、睡觉。不想长大。在寝室的最后一天,看着室友一个一个的走,没说再见,因为明白,以后很少会再见了。
  再回顾一下工作,只能说社会就是社会,资源就那么多,想自己不吃亏只能争,只能抢。我本来并不在意这些的,我觉得我做好自己的事情,我做的开心就好了,我不需要去争取,去竞争什么,到时间了,一切都会回报给我的。天真!后来发现,如果不去争取,那些不是我的当然不是我的,但是是我的也变成不是我的了。做人不能太低调了,低调没人会知道你做了什么。最近工作上一直有些负面情绪,有点难调节。
  工作对我的改变是大的,改变了很多我的想法,我渐渐变成了那些我曾经很厌恶的人,最近有点讨厌自己,觉得得再去读一读《瓦尔登湖》,找找内心的平静了。

2. 向前看

  2017过去了,新的一年,让新的思想支配新的我,争,争,争。还是很单纯,容易把事情想的极端了。想起以前C++老师在上课的时候跟我们说,当初她选择学计算机,就是觉得做这一行的,可以多动脑子,少动心眼,不用整那些七七八八的,有的没的。我一开始也是这么认为的,不想管那么多的事情,只想把自己的技术学好了,其他的顺其自然。但是在社会,如果只想着学号技术,其他不管不顾不闻不问,没办法顺其自然。
  新年新气象,新人新思想。   

3. 该利的flag还是要立

  该立的flag还是要立的,打脸是小事,没有目标才是大事。

  1. 多写博客,发给公司公众号,搞下自己公众号,提升自身影响力
  2. 多锻炼,依然是一个150斤的重量级人物了,虽然看不出来,但是几斤几两自己心里清楚,迫不得已可以加入健身房计划
  3. 多赚钱,做个俗人,要赚钱,多赚钱
  4. 自制力提升
  5. 使用刻意练习的方法掌握一门技能(技能未定)
      就这么多,反正在立下这些flag的时候,我是抱着完成目标的心态立的。
      欲知后事如何,请看来年年终总结。

博客地址:https://win-man.github.io/
公众号:欢迎关注