MySQL故障切换笔记之应用无感知设计详解
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
/**
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端返回的数据包中没有事务状态跟踪信息。
## 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格式解析
## 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的时候，会显示更加详细的事务状态信息。
客户端执行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节点故障切换了，对应用来说可以无感知的切换过去。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我们的支持。
相关推荐
-
Mysql 出现故障应用直接中断连接导致数据被锁（生产故障）详解
应用直接中断连接导致数据被锁(生产故障) 这是一个由应用重启连接直接而导致数据被锁的问题. 系统大致结构 基本情况: 整个架构为了统一管理db连接,共享连接. 应用通过loadbalance连接db访问层. db访问层后端代理若干db. 应用到loadbalance以mysql协议通信. db访问层到db以JDBC方式通信. 故障: 某些数据库中的表数据相当长一段时间被锁,导致应用某些场景失败. 故障分析:应用开启一个事务的set autocommit=0命令是从app-lb-db访问层-db,
-
mysql 无法联接常见故障及原因分析
===================================================================================================== 故障现象 : 无法连接 mysql 错误信息 :ERROR 2003 (HY000): Can't connect to MySQL server on 'hostxxxxx' (10061) 原因 : mysqld数据库服务没有启动. 检查 :在windows 的任务管理器,或者 unix/l
-
MYSQL主从库不同步故障一例解决方法
于是: 1.在主库中创建一个临时库,将需要导入的表文件复制过来 2.执行 create database tmpdb; create table tmptable; cp mysql_date_file master_data_file //shell command 复制数据表文件到master data_dir下 insert into master.tmptable select * from tmpdb.tmptable; 执行完后,主库中数据导入正常 再看slave status sh
-
一次MySQL慢查询导致的故障
我们知道分析MySQL语句查询性能的方法除了使用EXPLAIN 输出执行计划,还可以让MySQL记录下查询超过指定时间的语句,我们将超过指定时间的SQL语句查询称为"慢查询". 一. 起因 研发反应某台数据库僵死,后面的会话要么连接不上,要么要花费大量的时间返回结果,哪怕是一个简单的查询. 二. 处理 首先去监控平台查看服务器以及数据库状态,发现这台数据库有大量的慢查询.继续看服务器监控,CPU 平均使用率较高,IO 读写平均值正常.登录到 MySQL,使用 SHOW PROCESSL
-
MySQL下高可用故障转移方案MHA的超级部署教程
MHA介绍 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10-30秒内),完成故障切换,部署MHA,可避免主从一致性问题,节约购买新服务器的费用,不影响服务器性能,易安装,不改变现有部署. 还支持在线切换,从当前运行master切换到一个新的master上面,只需要很短的时间(0.5-2秒内),此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护. 在有高可用,数据一致性要求的系统上,MHA 提供了有用的功能
-
MySQL复制的概述、安装、故障、技巧、工具(火丁分享)
同MongoDB,Redis这样的NoSQL数据库的复制相比,MySQL复制显得相当复杂! 概述 首先主服务器把数据变化记录到主日志,然后从服务器通过I/O线程读取主服务器上的主日志,并且把它写入到从服务器的中继日志中,接着SQL线程读取中继日志,并且在从服务器上重放,从而实现MySQL复制.具体如下图所示: 整个过程反映到从服务器上,对应三套日志信息,可在从服务器上用如下命令查看: 复制代码 代码如下: mysql> SHOW SLAVE STATUS; Master_Log_File &
-
检测MySQL的表的故障的方法
表的故障检测和修正的一般过程如下: 检查出错的表.如果该表检查通过,则完成任务,否则必须修复出错的数据库表. 在开始修复之前对表文件进行拷贝,以保证数据的安全. 开始修复数据库表. 如果修复失败,从数据库的备份或更新日志中恢复数据. 在使用myisamchk或isamchk检查或修复表之前,应该首先注意: 建立数据库备份和使用更新日志,以防修复失败,丢失数据. 仔细阅读本章内容以后再进行操作,尤其是不应该在阅读"避免与MySQL服务器交互作用"之前进行操作.因为,在你没有足够的知识之前
-
线上MYSQL同步报错故障处理方法总结(必看篇)
前言 在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法. 生产环境架构图 目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务.在发生故障时,切换到slave上,并将其变成master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错.下面是我收录下来的报错信息. 常见错误 最常见的3种情
-
MySQL故障切换笔记之应用无感知设计详解
1. 简介 大家都知道,在数据库中间件读写分离应用场景中,如何保证底层数据库出现故障节点的时,中间件可以快速断开或迁移数据库连接,让用户无感知. 在MySQL数据库中,提供了一个session_track_transaction_info参数来提供解决方案. 因为官方文档上没有对该参数的说明,本文专门介绍该参数的可选值并验证了实际的影响.下面话不多说了,来随着小编一起看看详细的介绍吧 2. session_track_transaction_info参数 2.1 参数介绍 MySQL5.7中,可
-
SpringBoot项目多层级多环境yml设计详解
目录 需求场景 想要达到的效果 实现 需求场景 基础设施模块中有一些通用固定的基础配置.例如:日志的配置,Spring本身的配置以及MyBatis Plus相关的固定配置等等. 这些配置往往与环境无关,如何复用? # 日志配置 logging: level: # 记得配置到包名 com.agileboot: debug org.springframework: info pattern: console: "%date %thread %green(%level) [%cyan(%logger{
-
MySQL的视图和索引用法与区别详解
MySQL的视图 简单来说MySQL的视图就是对SELECT 命令的定义的一个快捷键,我们查询时会用到非常复杂的SELECT语句,而这个语句我们以后还会经常用到,我们可以经这个语句生产视图.视图是一个虚拟的表,它不存储数据,所用的数据都在真实的表中. 这样做的好处有: 1.防止有未经允许的租户访问到敏感数据 2.将多个物理表抽象成一个逻辑表 3.结果容易理解 4.获得数据更容易,很多人对SQL语句不太了解,我们可以通过创建视图的形式方便用户使用. 5.显示数据更容易. 6.维护程序更方便.调试视
-
Mysql InnoDB引擎中的数据页结构详解
目录 Mysql InnoDB引擎数据页结构 一.页的简介 二.数据页的结构 三.记录在页中的存储结构 四.记录头信息 1. deleted_flag 2. min_rec_flag 3. n_owned 4. heap_no 5. record_type 6. next_record Mysql InnoDB引擎数据页结构 InnoDB 是 mysql 的默认引擎,也是我们最常用的,所以基于 InnoDB,学习页结构.而学习页结构,是为了更好的学习索引. 一.页的简介 页是 InnoDB 管理
-
MySQL筑基篇之增删改查操作详解
目录 一.增加表中数据 1.无自增列时 2.有自增列时 二.删除表中数据 1.使用delete 2.使用truncate 三.修改表中数据 四.*查询操作 1.简单查询 2.条件查询 3.排序 一.增加表中数据 1.无自增列时 1.指定字段添加数据 给表中的部分列添加数据:值的顺序必须跟指定列的顺序保持一致 语法:insert into 表名(列1,列2,...) values(值1,值2,...) 2.默认添加数据 向表中的所有列添加数据:值的顺序必须跟字段顺序保持一致 语法:insert i
-
Android H5通用容器架构设计详解
目录 背景 术语对齐 探索 如何优雅地提供接口调用? 怎样封装多个不同类型的H5容器容器? 整体架构 通用容器 框架容器 基础组件 这样的架构能带来什么样的好处? 背景 大家如果经历过Hybrid项目的开发,即项目中涉及到H5与Native之间的交互,那么很有可能会遇到各种各样的H5容器.为什么会有那么多各种各样的容器呢...这也是轮子多的通病了,轮子多到业务方不知道选哪个.当然,也有可能大家压根就不会使用到H5容器,直接用系统WebView就完事儿了,比如我的前东家就是这样做的.那这篇文章的主
-
Golang学习之无类型常量详解
目录 什么是无类型常量 无类型常量的特性 默认的隐式类型 类型自动匹配 无类型常量带来的便利 无类型常量的坑 总结 因为虽然名字很陌生,但我们每天都在用,每天都有无数潜在的坑被埋下.包括我本人也犯过同样的错误,当时代码已经合并并发布了,当我意识到出了什么问题的时候为时已晚,最后不得不多了个合并请求留下了丢人的黑历史. 为什么我要提这种尘封往事呢,因为最近有朋友遇到了一样的问题,于是勾起了上面的那些“美好”回忆.于是我决定记录一下,一来备忘,二来帮大家避坑. 由于涉及各种隐私,朋友提问的代码没法放
-
mysql中inner join和left join使用详解
目录 区别 inner join 场景 inner join 场景 区别 返回不同1.inner join只返回两个表中联结字段相等的行2.left join的数量小于等于左表和右表中的记录数量. 数量不同1.inner join返回包括左表中的所有记录和右表中联结字段相等的记录.2.left join的数量以左表中的记录数量相同 记录属性不同1.inner join不足的记录属性会被直接舍弃2.left join不足的记录属性用NULL填充 inner join 场景 设计两张表: chann
-
Mysql的基础使用之MariaDB安装方法详解
我首次用mysql是在ubuntu上,现在用的是linux 中的Red Hat 分支的centOS 7 ,安装时发现通常用的都是MariaDB 来代替mysql,通过资料查询发现Mariadb是mysql的其中的一种分支,由mysql的创始人带领的团队所开发的mysql分支的一种版本,因为mysql受到被Oracle收购后的日渐封闭与缓慢的更新,众多Linux发行版逐渐抛弃了这个人气开源数据库,使MySQL在各大Linux发行版中的失势由于不满MySQL被Oracle收购后的日渐封闭与缓慢的更新
-
MySql批量插入优化Sql执行效率实例详解
MySql批量插入优化Sql执行效率实例详解 itemcontractprice数量1万左右,每条itemcontractprice 插入5条日志. updateInsertSql.AppendFormat("UPDATE itemcontractprice AS p INNER JOIN foreigncurrency AS f ON p.ForeignCurrencyId = f.ContractPriceId SET p.RemainPrice = f.RemainPrice * {0},