数据库
12 篇OnCall 无人值守讨论
将诊断迁移至 Agent 2.0，提高前置诊断的智能化程度，现在诊断时间最长能达到 5min，已经足够完成比较复杂的诊断了。 用户对 Agent 的容忍度（如何在用户耐心耗尽之前让人工介入避免投诉）：AI Agent 理论上能解决的范围，但是实际上更多还是依赖：“用户到底有多大意愿和 Agent 进行多轮对话”，如果用户提问时候提供足够多的背景信息，很多未拦截工单是可以前置拦截成功的。 知识库重构：现在已有的 OnCall 知识库更类似字节云文档，后续扩展到无人值守，很多诊断所依赖的背景知 …
将诊断迁移至 Agent 2.0，提高前置诊断的智能化程度，现在诊断时间最长能达到 5min，已经足够完成比较复杂的诊断了。 用户对 Agent 的容忍度（如何在用户耐心耗尽之前让人工介入避免投诉）：AI Agent 理论上能解决的范围，但是实际上更多还是依赖：“用户到底有多大意愿和 Agent 进行多轮对话”，如果用户提问时候提供足够多的背景信息，很多未拦截工单是可以前置拦截成功的。 知识库重构：现在已有的 OnCall 知识库更类似字节云文档，后续扩展到无人值守，很多诊断所依赖的背景知 …
TiFlash 存算分离架构踩坑实录
1 一、背景 TiFlash 的好处和适应范围，这里就不多介绍了，大家都知道 TiFlash 可以极大的提高 AP 类查询的效率，所谓的 HTAP 数据库里 AP 主要就是通过 TiFlash 来实现的，不过 TiFlash 是列存模式，是作为 TiKV 的 Follower 角色来实现的，如果想达到高可用的状态，至少得提供 2 个副本，这样只从存储成本上来讲，相当于存储成本增长了 2/3, 这对很多公司而言，无疑会导致成本大幅度上升。 而 TiFlash 存算分离架构 通过把存储转移到 S3 …
1 一、背景 TiFlash 的好处和适应范围，这里就不多介绍了，大家都知道 TiFlash 可以极大的提高 AP 类查询的效率，所谓的 HTAP 数据库里 AP 主要就是通过 TiFlash 来实现的，不过 TiFlash 是列存模式，是作为 TiKV 的 Follower 角色来实现的，如果想达到高可用的状态，至少得提供 2 个副本，这样只从存储成本上来讲，相当于存储成本增长了 2/3, 这对很多公司而言，无疑会导致成本大幅度上升。 而 TiFlash 存算分离架构 通过把存储转移到 S3 …
记一起 Schedule 卡住的问题
1 现象 业务反馈查询 TiFlash 报错：No access path for table 'dwd_id_mapping' is found with 'tidb_isolation_read_engines' = 'tiflash,tidb', valid values can be 'tikv'. 到集群中查看了一下，确实这个表的副本一直处于同步状态，但是进度一直没有发生变化。 看了下 PLACEMENT POLICY 状态，确实也处于 INPROGRESS状态 但是通过 …
1 现象 业务反馈查询 TiFlash 报错：No access path for table 'dwd_id_mapping' is found with 'tidb_isolation_read_engines' = 'tiflash,tidb', valid values can be 'tikv'. 到集群中查看了一下，确实这个表的副本一直处于同步状态，但是进度一直没有发生变化。 看了下 PLACEMENT POLICY 状态，确实也处于 INPROGRESS状态 但是通过 …
TiDB常用命令
-- 获取所有连接的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 …
-- 获取所有连接的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 …
TiDB 7.5资源管控能力测试
在7.1时候，其实已经对资源管控做了测试：TiDB 7.1 资源管控验证测试1。本文重点对7.1到7.5期间新增的资源管控能力进行测试，完整的功能特性见：TiDB 6.5升级7.5调研2 怎么理解RU Quota？如何设置合理的RU Quota？一个复杂查询的RU成本竟然会有7W！ 资源组的RU_PER_SEC限制的是资源组整体的消耗速度，可以看到RU的消耗其实是包含对TiKV读写请求封装的，虽然在TiKV层只有基于优先级的概念，没有直接对资源组做Quota限制，但是通过限制 …
在7.1时候，其实已经对资源管控做了测试：TiDB 7.1 资源管控验证测试1。本文重点对7.1到7.5期间新增的资源管控能力进行测试，完整的功能特性见：TiDB 6.5升级7.5调研2 怎么理解RU Quota？如何设置合理的RU Quota？一个复杂查询的RU成本竟然会有7W！ 资源组的RU_PER_SEC限制的是资源组整体的消耗速度，可以看到RU的消耗其实是包含对TiKV读写请求封装的，虽然在TiKV层只有基于优先级的概念，没有直接对资源组做Quota限制，但是通过限制 …
TiDB 7.1 资源管控验证测试
https://tidb.net/blog/9cd7dcb3 本文章的重点在通过实验探索资源管控的一些细节表现，详细来讲就是：TiDB的流控能力和TiKV的调度能力。 2024-01-29 16:48:39 1 〇、背景 我们线上使用环境和李文杰大佬比较类似，我这里就不赘述了，大家可以看专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区，这里比较清晰的介绍了7.1的资源管控原理和实践验证。 本文章的重点在通过实验探索资源管控的一些细节表现，详细来讲就是：TiDB的流 …
https://tidb.net/blog/9cd7dcb3 本文章的重点在通过实验探索资源管控的一些细节表现，详细来讲就是：TiDB的流控能力和TiKV的调度能力。 2024-01-29 16:48:39 1 〇、背景 我们线上使用环境和李文杰大佬比较类似，我这里就不赘述了，大家可以看专栏 - TiDB v7.1.0 跨业务系统多租户解决方案 | TiDB 社区，这里比较清晰的介绍了7.1的资源管控原理和实践验证。 本文章的重点在通过实验探索资源管控的一些细节表现，详细来讲就是：TiDB的流 …
TiDB抖动排查路径
1 select执行流程 2 INSERT流程 2.1 落盘步骤 3 故障排查流程 #TiDB# #故障排查#
1 select执行流程 2 INSERT流程 2.1 落盘步骤 3 故障排查流程 #TiDB# #故障排查#
常用MySQL命令
将某个字段/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过滤指定 …
将某个字段/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过滤指定 …
MySQL slow_log日志采集方案
1 MySQL slow_log日志采集方案 1.1 背景 慢查询对线上的影响很大，而慢日志是发现慢查询SQL的最常用手段，所以对慢日志的收集和监控，是作为一个DBA的最常见需求。下面介绍一下常见的慢日志收集方案 slow-query-log 5.4.1 Selecting General Query Log and Slow Query Log Output Destinations 5.4.7 Server Log Maintenance 1.2 方案一：将日志写入到表中，从表中定时获取慢查 …
1 MySQL slow_log日志采集方案 1.1 背景 慢查询对线上的影响很大，而慢日志是发现慢查询SQL的最常用手段，所以对慢日志的收集和监控，是作为一个DBA的最常见需求。下面介绍一下常见的慢日志收集方案 slow-query-log 5.4.1 Selecting General Query Log and Slow Query Log Output Destinations 5.4.7 Server Log Maintenance 1.2 方案一：将日志写入到表中，从表中定时获取慢查 …
一次TiDB负载搞排查
背景 TiDB Server两个节点CPU使用率都比较高 查看QPS指标，可以看到14点到19点之间是基本没有流量的 登陆机器可以发现，有很多连接其实已经失效，但是还残留服务器上： 怀疑Server负载高和这些诡异的SQL有关系，即便没有释放，也没办法KILL，但是还是占用了一个核的CPU https://github.com/pingcap/tidb/pull/29212 https://github.com/pingcap/tidb/issues/24031 解决方案 将流量转移到其他机器， …
背景 TiDB Server两个节点CPU使用率都比较高 查看QPS指标，可以看到14点到19点之间是基本没有流量的 登陆机器可以发现，有很多连接其实已经失效，但是还残留服务器上： 怀疑Server负载高和这些诡异的SQL有关系，即便没有释放，也没办法KILL，但是还是占用了一个核的CPU https://github.com/pingcap/tidb/pull/29212 https://github.com/pingcap/tidb/issues/24031 解决方案 将流量转移到其他机器， …
MySQL在线更改Binlog目录
背景 线上使用共享表空间，因共享表空间没办法释放，导致磁盘可用空间太小，所以新找几台机器，重新导出导入，将业务迁移到新机器上。 因需要从备机导数据，需要保留binlog个数不固定，为避免导数机器被binlog撑满，将其他磁盘的目录挂载到binlog目录。 原理 将binlog目录挂载到其他分区 重新生成binlog/relay log日志，使其在新目录生成 注1：因为操作会进行reset master操作，所以不适用下游有空库或者其他拉取binlog的服务(如DM、Debezium等) 注2：如 …
背景 线上使用共享表空间，因共享表空间没办法释放，导致磁盘可用空间太小，所以新找几台机器，重新导出导入，将业务迁移到新机器上。 因需要从备机导数据，需要保留binlog个数不固定，为避免导数机器被binlog撑满，将其他磁盘的目录挂载到binlog目录。 原理 将binlog目录挂载到其他分区 重新生成binlog/relay log日志，使其在新目录生成 注1：因为操作会进行reset master操作，所以不适用下游有空库或者其他拉取binlog的服务(如DM、Debezium等) 注2：如 …
MySQL搭建Group Replicatiion
1. 安装MySQ(>=5.7.19) 具体安装方法，请百度或Google 2. GR准备工作 1. 更改配置文件 loose-为配置前缀，后边才是变量名。 正常情况下配置文件里参数是必须可用的，也就是必须先安装插件，后改配置文件，否则MySQL启动时会报错。加loose-前缀后，如果参数不存在，会先忽略报错，待插件安装后，会自动将对应参数设置为配置文件的值。 # group replication binlog_checksum=NONE …
1. 安装MySQ(>=5.7.19) 具体安装方法，请百度或Google 2. GR准备工作 1. 更改配置文件 loose-为配置前缀，后边才是变量名。 正常情况下配置文件里参数是必须可用的，也就是必须先安装插件，后改配置文件，否则MySQL启动时会报错。加loose-前缀后，如果参数不存在，会先忽略报错，待插件安装后，会自动将对应参数设置为配置文件的值。 # group replication binlog_checksum=NONE …