TiKV 的分成设计中最上层封装了各种 RPC 请求类型(kv_get, kv_batch_get, batch_commands, prewrite, coprocessor …) [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] 这个抛错应该是 TiDB 那边有发 batch_commands 类型的 SQL 正常 或 异常 终止请求的过程中, tikv 侧的的 rpc request 日志 当然不止 tidb 会发请求, 其他工具 BR 等都有可能, 不过 大量 应该还是 tidb 的可能性比较大

您好, 感谢反馈, 应该是个已知问题 已经修复了, 修复方法与您的临时方案一致(batch) 详见 : OOM in the ClearOutdatedHistoryStats · Issue #48431 · pingcap/tidb (github.com) [image]

连的是 serverless 吗(serverless 要安全链接)? 还是 OP tidb? 如果 tidb log 也只有 用户密码无效, 那应该还是驱动或者 发过来的请求有问题, 抓个包? 看用 ODBC 的链接跟 JDBC 比应该也没啥区别, 能想到也就是驱动了, 不行抓包吧 tableau 连接mysql的操作步骤 - 知乎 (zhihu.com)

建议, 这问题转到 TiDB Internals 或者 github tikv repo 交流吧🤔

是这样的, 官网其实有 FAQ : TiDB 安装部署常见问题 | PingCAP 文档中心 贴这里, 方便大家搜索!!

昨天晚上 修改了与之前tiflash 完全不一样的端口可以挂上tiflash了. –》 应该是 dba-kit 老师说的: “你混部的场景是把TiFlash和谁混部了啊，看下是不是端口冲突了。找了下TiFlash的端口还是挺多的” 之类的问题, 或者进程没清理干净. 但是发现tiflash 没有任何同步动作. –》 这个在 tiflash 进程状态正常, 且设置 tiflash 副本后, 还没有进度, –》 就需要重新看 tiflash 最近产生的日志了 tiup cluster prune xxxxtidb --force –》 不要用, --force, force 是忽略一…

麻烦测试环境测一个稳定复现的 最小复现步骤, 谢谢?

我用 FRP 在自己的腾讯云上 内网穿透了下 证明 : 如果你访问公网的请求能正确接到 pd 的 tidb-dashboard 的 http 端口上, tidb 就支持访问 感觉楼上说的 反向代理 是一种可能 不过我没发往下测了, 因为我的云服务器连拉起 playground 的配置都不够😂 不过我感觉, 还是云那边设置的有问题(安全 防火墙 啥的…) [image] [image]

如果能确定是 tikv 日志的影响原因的话, 估计就要分析下为什么这个 tikv 与其他 tikv 相比打印过多日志了. 是什么日志 tikv.log? rocksdb log? or 其他? 最好还是加个 crontab 实锤 log 与磁盘占用之间的关系, 这里有个关键点是 还是持续增长的量有多大 还有之前不均衡的现象是你删完日志就恢复了吗?删的是哪类日志等 实锤后再分析, 哪类日志, 为什么产生, 规避 … 基本确定是 日志 的话, workaround 就删吧 如果是不重要日志, crontab 脚本 tick 占用量, 删也行, 就是有点粗暴

抱歉, 我只会在某一段时间看 TUG 的帖子, 有时候回消息会出现不及时的情况 现象 : 从 store region score 看, PD 已经识别到 tikv-24 有很高的 score 了, 按理说会往下降低; 但是这个时间段, region score 还在涨, 说明磁盘空间使用在涨, 不像是 PD 的主动行为 [image] region size 很低, 说明这上面的真实数据少(reigon 少), 而且还在进一步减少 [image] region count 很低, 而且还在进一步减少 [image] 半个小时时间 磁盘可用空间骤降 [image] …

选最佳答案就标志结束, 可能是当时我看的时候还没选

是否要导出问题时间的mertics？ –》 是的 我的集群版本是5.0.4不知道能不能行。 –〉 我记忆里 v5 已经可以了(我好像还用过), 可以 grafana --version, 如果满足这个要求就可以 应该还是操作问题 [image]

上面任意一个执行计划慢的 SQL 麻烦贴一下 文本; 表明啥的可以一类同意替换掉, 比如: table_x → table_y(脱敏) 比如这个 [image] 看 dashboard 里面乖乖的, 具体的执行情况看着都不慢, 总时间慢了🤔

[image] 导出的有点问题🤔

[image] PingCAP MetricsTool 等所有 监控全是打开状态, 并渲染出图像后, 按照步骤 就可以导出 json 文件了

嗯嗯 metrics 默认保存 30d, 这个应该还在, 历史记录持久化在 prometheus 里的

目前信息太少, 这个报错都不是全的吧? 看 v5 有类似的内容, 感觉 v6.5.1 了应该早修了 如果自己看, 可以借鉴一下 5.0.0 upgrade to 5.0.1-pre, report “table reader fetch next chunk failed” · Issue #24148 · pingcap/tidb (github.com) 的思路 感觉日志后面应该会写指向 Transaction is corrupted by either missing data from default CF or some part of transaction are ro…

operator 有 create 有被 cancel 吗? metrics 里如果有 cancel, 应该能 cancel 的原因 来份时间长点的 pd metrics 导出图 PingCAP MetricsTool

发一份 tikv-details metrics? PingCAP MetricsTool