作者:文韵涵
爱可生 DBLE 团队开发成员,主要负责 DBLE 需求开发,故障排查和社区问题解答。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
问题背景
在使用某些 GUI 工具连接 DBLE 操作时,会因为某些 SQL 在 DBLE 中不兼容导致 GUI 工具出现异常不能正常使用。
通常排查方案:
-
步骤一:需要知道 GUI 工具操作时下发了哪些 SQL 至 DBLE ;一般用 tcpdump 、Wireshark 等抓包工具获取 SQLs
-
步骤二:将 SQLs 逐个在 Mysql Client 中执行,定位问题 SQL
排查案例1
登陆 phpMyAdmin 首个界面,未展示数据库列表
GUI 工具: phpMyAdmin 7.4.20 (这里用的是docker)
DBLE 版本:3.21.02.x
##docker方式搭建phpMyAdmin
## 拉取phpmyadmin镜像
$ docker pull phpmyadmin/phpmyadmin
##初始化phpmyadmin容器 且关联dble服务
$ docker run -d --name myadmin_aliyun -e PMA_HOST=xxx.mysql.rds.aliyuncs.com -e PMA_PORT=3xx6 -p 8081:80 phpmyadmin/phpmyadmin
##详解:
-d:以后台模式运行
--name myadmin: 容器命名为 myadmin, 容器管理时用(启动/停止/重启/查看日志等)
-e PMA_HOST=xx.xxx.xx.xx: Dble服务器域名或IP地址
-e PMA_PORT=8066: Dble的8066端口
-p 8080:80: 端口映射, 本地端口:容器端口, 访问: http://ip:8080
phpmyadmin/phpmyadmin: 要初始化的镜像名
访问 http://ip:8080 ,使用 DBLE 的 8066 用户密码登陆;登入后的界面发现未展示数据库列表,如下图:
为什么没有展示数据库列表呢?
排查步骤一:
先下载 tcpdump(用于抓包)、Wireshark(查看包)工具;然后执行 tcpdump 命令采集操作(登入 phpmyadmin 后的界面)期间的 tcp 协议传输生成 cap 文件,然后将其文件放置 Wireshark 中转成 Mysql 协议然后过滤(如下图)方便阅读、排查以及提取下发的所有 SQLs ;(实际上需要逐个点开 Request Query 然后手动提取 SQL )
排查步骤二:
将收集的 SQLs 逐个在 Mysql Client 中执行,定位到问题 SQL (原因:phpMyAdmin 下发查询库列表时,DBLE 返回空结果集)
具体问题 SQL :
-
SELECT
SCHEMA_NAME
FROMINFORMATION_SCHEMA
.SCHEMATA
, (SELECT DB_first_level FROM ( SELECT DISTINCT SUBSTRING_INDEX(SCHEMA_NAME, ‘’, 1) DB_first_level FROM INFORMATION_SCHEMA.SCHEMATA WHERE TRUE ) t ORDER BY DB_first_level ASC LIMIT 0, 100) t2 WHERE TRUE AND 1 = LOCATE(CONCAT(DB_first_level, '’), CONCAT(SCHEMA_NAME, ‘_’)) ORDER BY SCHEMA_NAME ASC; – 查询所有库 -
2021-08-06T15:33:28.350 9 Query SELECT COUNT(*) FROM ( SELECT DISTINCT SUBSTRING_INDEX(SCHEMA_NAME, ‘_’, 1) DB_first_level FROM INFORMATION_SCHEMA.SCHEMATA WHERE TRUE ) t; – 查询库的个数
在步骤一中,需要用到额外工具协助排查,可能需要储备一些知识(如:TCP 协议、抓包命令);于是,非开发人员排查此问题是比较苦恼的。
general log
开启 general log ,将所有到达 DBLE 的 SQL 语句记录下来。这样一来不再需要使用抓包工具就可以拿到所有 SQLs(直接进入步骤二)
具体见general日志:
https://actiontech.github.io/dble-docs-cn/2.Function/2.27_general_log.html
相关参数
-
enableGeneralLog:general log 的开关标识,1-开启、0-关闭
-
generalLogFile:general log 文件的存储路径
-
generalLogFileSize:触发文件翻转的大小,当超过16MB则将 general.log 翻转为 yyy-MM/general-MM-dd-%d.log 的格式文件
-
generalLogQueueSize:内部实现机制队列用到的大小,默认4096
以上参数在 bootstrap.cnf 中配置,在这个配置中的更变,需要充气后才能生效。
相关命令
-
show @@general_log; – 查询 general log 的开关状态和文件路径
-
enable @@general_log; – 开启 general log
-
disable @@general_log; – 关闭 general log
-
reload @@general_log_file=’/tmp/dble-general/general/general.log’; – 修改 general log 的文件路径
以上命令仅管理端支持执行,立即生效,不需要重启 DBLE 。另外下次重启 DBLE 的时候会保留当前设置,不会丢失。
版本
- 从 DBLE3.21.02 版本开始引入 general log ;(之前的版本不支持)
性能
- 开启 general log 后,DBLE 性能损耗在3~5%之间;建议在排查某些错误临时打开,等调试完后关闭
输出类型
- 与 Mysql 相比,DBLE 的 general log 的输出类型只有 File 模式
打印格式
- 开启后,记录格式(与 Mysql 的 general log 格式一致)
/FAKE_PATH/mysqld, Version: FAKE_VERSION. started with:
Tcp port: 3320 Unix socket: FAKE_SOCK
Time Id Command Argument
2021-08-05T16:24:53.558 1 Query select * from no_sharding_t1
2021-08-05T16:25:00.210 1 Query desc tb_grandson1
2021-08-05T16:26:32.774 1 Query desc sharding_2_t1
2021-08-05T16:26:37.990 1 Query select * from sharding_2_t1
2021-08-05T16:26:54.862 1 Query insert into sharding_2_t1 values(1,1,1,1,1)
实现机制
DBLE 中 general log 的异步落盘机制具体的实现参考log4j
具体实现
-
同步处理
- 将 sql 包装为 Log ;Log 包含 Time、Id、Command、Argument 等信息
- 将 Log 放置 generalLog 队列中;(若队列已满时,会一直阻塞在此处,直到队列有空闲位置)
- sql 的后续流程处理
-
异步处理
- 监听队列且处理队列
- 当前 Log 的 byte 大小 <= Buffer 缓存剩余空间(默认4096),则先入 Buffer 缓存中;后续 Buffer 缓存满了会触发落盘
- 当前 Log 的 byte 大小 > Buffer 缓存剩余空间, 先将 Buffer 缓存中的 Log +当前 Log 直接落盘
- 因为采用了 Disruptor(generalLog 实际上是一个环形队列),入队计算会决定是否为批量处理的状态,如果为批量处理,也会触发将 Buffer 缓存中的 Log/ 当前 Log 的落盘
- 翻转条件:日期变动(每天) || general.log 的大小>generalLogFileSize 时