张天师 on DBA学习笔记

OnCall 无人值守讨论

281304173@qq.com (张天师) — Fri, 16 Oct 2026 10:10:40 +0800

将诊断迁移至 Agent 2.0，提高前置诊断的智能化程度，现在诊断时间最长能达到 5min，已经足够完成比较复杂的诊断了。

用户对 Agent 的容忍度^{（如何在用户耐心耗尽之前让人工介入避免投诉）}：AI Agent 理论上能解决的范围，但是实际上更多还是依赖：“用户到底有多大意愿和 Agent 进行多轮对话”，如果用户提问时候提供足够多的背景信息，很多未拦截工单是可以前置拦截成功的。

TiFlash 存算分离架构踩坑实录

281304173@qq.com (张天师) — Sat, 14 Dec 2024 20:30:47 +0800

1 一、背景

TiFlash 的好处和适应范围，这里就不多介绍了，大家都知道 TiFlash 可以极大的提高 AP 类查询的效率，所谓的 HTAP 数据库里 AP 主要就是通过 TiFlash 来实现的，不过 TiFlash 是列存模式，是作为 TiKV 的 Follower 角色来实现的，如果想达到高可用的状态，至少得提供 2 个副本，这样只从存储成本上来讲，相当于存储成本增长了 2/3, 这对很多公司而言，无疑会导致成本大幅度上升。

记一起 Schedule 卡住的问题

281304173@qq.com (张天师) — Thu, 28 Nov 2024 11:25:06 +0800

1 现象

业务反馈查询 TiFlash 报错：No access path for table 'dwd_id_mapping' is found with 'tidb_isolation_read_engines' = 'tiflash,tidb', valid values can be 'tikv'.

到集群中查看了一下，确实这个表的副本一直处于同步状态，但是进度一直没有发生变化。

TiDB常用命令

281304173@qq.com (张天师) — Mon, 29 Jan 2024 18:05:03 +0800

-- 获取所有连接的session级别变量信息 
select * from PERFORMANCE_SCHEMA.session_connect_attrs limit 10;

-- 统计Placement Rule个数
cat rules.json | jq -c '.[] | {"group_id": .group_id, "id": .rules[].id}' | grep -c "TiDB_DDL"

-- 统计TiFlash副本的表(分区)个数
cat rules.json | jq -c '.[] | {"group_id": .group_id, "id": .rules[].id}' | grep -c "tiflash"

-- 统计TiFlash表在TiKV的数据量是多少
select t.table_schema, round(sum(t.data_length)/pow(1024,3), 2) as size_G from information_schema.tables t join information_schema.tiflash_replica r on t.table_schema=r.table_schema and t.table_name = r.table_name group by table_schema order by size_G;

-- 查看tiflash迁移进度
select t.table_schema, t.table_name, r.progress, round(t.data_length/pow(1024,3), 2) as size_G from information_schema.tables t join information_schema.tiflash_replica r on t.table_schema=r.table_schema and t.table_name = r.table_name where r.progress != 1 order by size_G;

-- 7.5版本不支持DISABLE_PRECHECK参数，8.1才支持
IMPORT INTO ying99_asset.service_account_info_latest FROM 's3://mysql-dts-migrate/asset-tidb-20240714-new/ying99_asset.service_account_info_latest.*.sql?access-key=LTAI5tMVKDBdFTLEsQ6afMdV&secret-access-key=kpjA0LED8BfKAraqzqnqbOZdNdSWy6&endpoint=https://oss-cn-shenzhen-internal.aliyuncs.com&force-path-style=false' FORMAT 'SQL' WITH CLOUD_STORAGE_URI="s3://mysql-dts-migrate/import-sort-dir?access-key=LTAI5tMVKDBdFTLEsQ6afMdV&secret-access-key=kpjA0LED8BfKAraqzqnqbOZdNdSWy6&endpoint=https://oss-cn-shenzhen-internal.aliyuncs.com&force-path-style=false", DETACHED;

‍

TiDB 7.5资源管控能力测试

281304173@qq.com (张天师) — Mon, 29 Jan 2024 17:01:39 +0800

在7.1时候，其实已经对资源管控做了测试：TiDB 7.1 资源管控验证测试¹。本文重点对7.1到7.5期间新增的资源管控能力进行测试，完整的功能特性见：TiDB 6.5升级7.5调研²

怎么理解RU Quota？如何设置合理的RU Quota？一个复杂查询的RU成本竟然会有7W！
资源组的RU_PER_SEC限制的是资源组整体的消耗速度，可以看到RU的消耗其实是包含对TiKV读写请求封装的，虽然在TiKV层只有基于优先级的概念，没有直接对资源组做Quota限制，但是通过限制TiDB发送给TiKV 的请求数量，来间接达到TiKV基于 Quota的限制。

测试计划？？

1 什么是 Request Unit (RU)

Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的计量单位，用于表示对数据库的单个请求消耗的资源量。请求消耗的 RU 数量取决于多种因素，例如操作类型或正在检索或修改的数据量。目前，RU 包含以下资源的统计信息：

TiDB 7.1 资源管控验证测试

281304173@qq.com (张天师) — Mon, 29 Jan 2024 16:48:40 +0800

https://tidb.net/blog/9cd7dcb3
本文章的重点在通过实验探索资源管控的一些细节表现，详细来讲就是：TiDB的流控能力和TiKV的调度能力。
2024-01-29 16:48:39

1 〇、背景

我们线上使用环境和李文杰大佬比较类似，我这里就不赘述了，大家可以看专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区，这里比较清晰的介绍了7.1的资源管控原理和实践验证。

TiDB抖动排查路径

281304173@qq.com (张天师) — Tue, 23 Jan 2024 15:24:54 +0800

1 select执行流程

2 INSERT流程

2.1 落盘步骤

‍

常用MySQL命令

281304173@qq.com (张天师) — Tue, 23 Jan 2024 15:24:38 +0800

将某个字段/binary类型转换为utf8字符集的方法
```
CONVERT(job_meta USING utf8) COLLATE utf8_unicode_ci
```

统计BINLOG中EVENT分布

# 按照时间段解析BINLOG
mysqlbinlog -vv --start-datetime "2022-04-01 03:02:00" --stop-datetime "2022-04-01 03:08:00" mysql-bin.002572 >2572.txt

# 将BINLOG过滤指定EVENT名到文件中
cat 2572.txt | grep -E "^SET TIMESTAMP|### (INSERT|UPDATE|DELETE)" >table.txt
# 查看单个事务的更改行数
uniq -c table.txt
# 统计某个时间段EVENT分布情况
sort table.txt | uniq -c | sort -n -k1

删除非系统库表

MySQL slow_log日志采集方案

281304173@qq.com (张天师) — Tue, 23 Jan 2024 15:24:10 +0800

1 MySQL slow_log日志采集方案

1.1 背景

慢查询对线上的影响很大，而慢日志是发现慢查询SQL的最常用手段，所以对慢日志的收集和监控，是作为一个DBA的最常见需求。下面介绍一下常见的慢日志收集方案

Caddy泛域名配置 && hugo自动更新

281304173@qq.com (张天师) — Fri, 08 Jul 2022 15:43:45 +0800

背景

在腾讯云买了个轻量服务器，就想部署一些self-hosted服务，带来的一个后果就是要配多个域名，申请多套SSL证书。一开始还好，很快就能申请好，不过随着域名的增多，有时候新加域名得等一段时间才能申请成功。好在caddy是支持泛域名证书(Wildcard certificates)：

待填的坑

281304173@qq.com (张天师) — Tue, 24 May 2022 17:13:01 +0800

最近刚开始写blog，需要抽时间将之前的知识梳理一下，包括不限于：

MySQL
TiDB
Linux相关：ZFS, Openwrt等
编程语言：SHELL, Python, Golang等
工具类：Shadowsocks, Minio, NextCloud
Mac: MarkText
博客: Caddy, Hugo, Picgo

PS: 不一定能写完，看情况吧🙈

一次TiDB负载搞排查

281304173@qq.com (张天师) — Tue, 24 May 2022 16:11:36 +0800

背景

TiDB Server两个节点CPU使用率都比较高
查看QPS指标，可以看到14点到19点之间是基本没有流量的
登陆机器可以发现，有很多连接其实已经失效，但是还残留服务器上：
怀疑Server负载高和这些诡异的SQL有关系，即便没有释放，也没办法KILL，但是还是占用了一个核的CPU
- https://github.com/pingcap/tidb/pull/29212
- https://github.com/pingcap/tidb/issues/24031

解决方案

将流量转移到其他机器，可选途径有：

HUGO主题相关内容

281304173@qq.com (张天师) — Sun, 22 May 2022 16:11:36 +0800

安装主题

安装主题可以通过两种途径：

直接下载主题的ZIP文件，将文件解压到theme目录下。
通过git submodel方式，将主题作为git子模块来管理。

建议通过git submodel方式来管理，这样后续主题有更新，直接通过git submodel来更新即可。

MySQL在线更改Binlog目录

281304173@qq.com (张天师) — Fri, 20 May 2022 22:07:16 +0800

背景

线上使用共享表空间，因共享表空间没办法释放，导致磁盘可用空间太小，所以新找几台机器，重新导出导入，将业务迁移到新机器上。
因需要从备机导数据，需要保留binlog个数不固定，为避免导数机器被binlog撑满，将其他磁盘的目录挂载到binlog目录。

MySQL搭建Group Replicatiion

281304173@qq.com (张天师) — Fri, 20 May 2022 15:55:22 +0800

1. 安装MySQ(>=5.7.19)

具体安装方法，请百度或Google

2. GR准备工作

1. 更改配置文件

loose-为配置前缀，后边才是变量名。正常情况下配置文件里参数是必须可用的，也就是必须先安装插件，后改配置文件，否则MySQL启动时会报错。加loose-前缀后，如果参数不存在，会先忽略报错，待插件安装后，会自动将对应参数设置为配置文件的值。

Linux端口转发方式

281304173@qq.com (张天师) — Wed, 18 May 2022 23:52:08 +0800

ssh端口转发模式

这种方式，有以下特点：

可以在本地执行，也可以在服务器执行，部署方案灵活；

通信会经过ssh加密，安全性好；

同样是因为经过ssh加密，所以性能比较低

ssh -L ${local_port}:${server_ip}:${server_port} -fN root@${proxy_ip}

xinetd 端口转发

没有加密，性能高；

在应用层转发，不需要root权限

安装xinetd：yum install -y xinetd