WalterWj
WalterWj
V10
萌新
2019-11-27 加入
获赞
421
回答
2131
文章
22
    cdc 使用最好在 tidb 6.5 最新版本以上。 低于这些版本问题比较多。 你 5 的版本可以考虑用 binlog 过度来迁移升级。
    20 小时前
    AI 解析: 社区问题分析报告:TiKV LIKE 表达式 Panic 问题链接: tikv 重启后一直 panic 无法稳定 1. 问题定性 TiKV 在 coprocessor 执行下推的 LIKE 表达式时 panic,调用链: impl_like::like (impl_like.rs:50) → Like_Fn::eval → BatchSelectionExecutor::handle_src_result → coprocessor::endpoint::Endpoint::handle_unary_request_impl Panic 原因:range …
    4 天前
    没有统一的。 如果只是代码学习可以不用切版本,如果自己想做开发等需要切换对应分支。
    5 天前
    AI 分析: 社区帖子 1056938 结论 根因:tiflash#10163(JoinPartition.cpp Arena::alloc 不保证对齐 → aarch64 上 std::mutex 触发 SIGBUS → TiFlash 进程崩溃)。x86 不崩(硬件容忍非对齐),aarch64 必崩。Bug 2023-11 引入,2025-05-19 修复(PR #10175),v8.1.2(2024-12 发布)带 bug、不带修复。 给客户的话术(5 分钟生效): server_configs: tiflash: profiles: default: join_probe_ca…
    11 天前
    使用 源码 agent 核对了下上面内容: @王军 独立跑了 pprof 并核对了源码,@ticket_new 的大方向对(瓶颈在 sorter 读路径,不是下游 sink),但参数名、机制细节、根因定位有 4 处明显偏差。 一、数据/数学核对(:white_check_mark: 全对) 项 @ticket_new 实测 核对 总采样 1254.17s / 4158.60% 同 :white_check_mark: sinkWorker.handleTask cum 548.23s/43.71% 同 :white_check_mark: 其中 FetchByTable 占比 96.78% 530.59/548.23 = 96.78% :white_check_mark: FetchByTable 总量 …
    15 天前
    AI 火焰图分析:cdc.zip 分析完成(cpu.prof + goroutine.txt,采集时间 2026-06-25 16:07 CST)。 CPU Profile 关键数据 指标 值 采集时长 30.16s 总 CPU 采样 1254.17s(4158.60%,约 41 核满载) 总 goroutine 1824 CPU 热点分布(按累计) 路径 累计 CPU 占比 说明 SourceManager.FetchByTable → EventSorter.FetchByTable → pebble.iterTable 717.90s 57.…
    15 天前
    AI 问题分析: 从 v7.1.3 升级到 v8.5.3 后,TiCDC 到 TiDB 下游的 changefeed 出现 CPU 持续攀升,这是 v8.x 版本 TiDB sink 的事务编码和冲突校验逻辑变化导致的已知行为。Kafka sink 不受影响是因为它不涉及 TiDB 批量写入校验。 capture tables 归零原因: CPU 耗尽后 TiCDC 节点无法向 Etcd 发送心跳维持 session,capture 被判定失活,其负责的表所有权自动转移到其他节点。进程未崩溃是因为底层 goroutine 仍在运行,只是丧失了调度能力。 建议处理方案: 升级到 v8…
    16 天前
    :thinking: 我用我的 loop tidb 问题分析团队分析下你这个问题。晚点给你分析结论。
    16 天前
    业务上是不是有什么 truncate table 的操作? 可以考虑升级到 v8.5.5 版本
    16 天前
    优化 SQL 确实是一个好办法 :smile:
    18 天前
    推荐拆节点吧。 还有这个内存消耗大的 sql 跑过 tiflash mpp 么?是否能优化?
    22 天前
    对了,这个参数来说,gogc 25 有点太低了。。。。我记得默认是 200 还是 100 来着🤔。是遇到 go gc 不及时 oom 的问题调整的么?
    1 个月前
    按照你的描述,看你也找到对应 SQL 了,推荐单独搞个 tidb-server 节点给这个 SQL 用,隔离开。。。
    1 个月前
    39.1 的服务器内存,SQL 要跑到 32GB 呗。。。
    1 个月前
    怎么判断你没有用到 swap 的?看一下 node_export 相关监控呢。 swap 一般推荐关闭
    1 个月前
    服务器 swap 关了么?
    1 个月前
    去掉很快,结果满足你么你要求么?满足的话就去掉吧。
    1 个月前
    用 Loop :arrow_right: 试用入口:loop.pingkai.cn :technologist: 新人上手指南:「新手必看」Loop 《新手上手指南》 :heart_hands: 使用问题反馈:Loop 专区 - TiDB 的问答社区 调一些 agent 出来。
    1 个月前
    :rofl: 难绷,要不要试试重启下服务器。 我感觉重启有效果 :grimacing:
    1 个月前