[image]

感谢社区的用心

赞同同 ID 张雨齐0720 老师的建议 TiCDC 项目背景、工具位置、使用情况、使用方法，可参考 https://tidb.net/blog/70588c4c 及官方文档。

生产环境还是测试环境？ 这里的 Region 信息都是从 PD API get 到的，按理说只要 start_key 和 end_key 都一致就是一个 Region，至此推断应该是在 TiDB 测算的时候出现了问题。 看 5.2 和 v6.0 这块计算的时候有些区别，最新版在这个 PR --> https://github.com/pingcap/tidb/pull/33498/files 加了 region id 为 key 的 map 合并方式，估计新版本可能就不会有这种现象了，如果是测试环境，可以升级一下。 [image]

下发了 15 个并发 cop task ，在 tikv 执行数据扫描时是并行的，那么返回数据给 tidb 是并行还是按某种顺序串行的？ 返回给 tidb 的数据是并行的，如果结果集无序，则所有并发的 request 结果会返回给一个全局 response channel。如果结果集有序，则所有并发的 request 结果返回到各 worker 各自 channel，随后处理保证结果有序性。当前 select * from XXX limit 1 无序结果结合为例，则全局 channel 并行接收 tikv 并发返回的结果到一个 response channel。 参考描述 “在 cop…

从全局看，14:30 出现 lag。 [image] [image] Owner 维护全局的同步状态，更新所有 changefeed 的全局 CheckpointTs 和 ResolvedTs； Processor 根据全局 ResolvedTs 推进自己节点的数据向下游同步；即：全局的 ResolvedTs 落后导致 Processor 的 checkpointTs 落后； 一般而言，各组件的 checkpointTs 在未出现异常状态下，就是组件自己负责的最后一个 ResolvedTs； 本例中，最小的 Processor CheckpointTs 是 IP 222 的 14:30…

个人拆分上述为 4 个问题： 1.在禁用 topn_push_down 后， 为什么执行计划显示 1 个 cop task 而 trace 里却有15个？ 2.在禁用 topn_push_down 后， 其余 14 个 cop task 是否真正的执行了？ 3. tablereader 算子返回 32 行是依据什么算来的？ 4. 在禁用 topn_push_down 后，调整 tidb_distsql_scan_concurrency=1, trace 等同于 1 的原因？ First ASK: 为什么执行计划显示 1 个 cop task 而 trace 里却有15个？ F…

首先，store id 0 在 TiKV 中是 INVALID_ID，tikv 初始化会给每个新的 new store 先置 store id 置 0 ，再去 PD alloc id 号，合理表现不应该出现 store ID == 0 from - -> https://github.com/tikv/tikv/blob/193d8cad8075ec4266c840b064dbeb8fcd0685c2/src/server/node.rs#L107 其次，从 “request failed” 这个 error message 看，在 TiKV 只有在 components/pd…

可以把建表语句脱敏，贴出来； 因为 tiflash 的数据是从 tikv 拉，如果 tidb 里面建表就有问题，极有可能导致 tiflash 拉数据的时候解析出问题。 或触发了某些 tikv 和 tiflash 之间的限制 或 BUG。

原理同 @h5n1 老师解释的那样； 可以发下 LockResolve OPS 的面板 如果业务没有影响，可以当内部解锁机制去处理。 可能是有什么事务崩溃执行失败，导致锁未及时清除。 深追就要看下日志里哪些 事务执行失败了之类的。

ASK : pump 数据目录下面的.ldb和.vlog 分别是什么文件? Answer: 首先，PUMP 内部封装了 LevelDB 去存储数据； 其次，.ldb 和 .vlog 是 leveldb 核心数据库文件，从 leveldb 1.14 版本以后不在以.sst 作为后缀名。 key 存在 .ldb 中，value 存到 .vlog 中。 ASK :如果数据目录空间不足，可以手动rm删除嘛? Answer: 不可以，PUMP 会自动维护 LevelDB，对外部用户透明。如果数据目录空间不足，需排查出具体原因再解决。配合监控 --> https://docs.pingcap…

存储统计信息的等深直方图 BUCKET 和 NDV 等相关数据，系统会自动维护。

首先，在 Dashboard 启动的时候，会先把这个 service 注册到服务里面，JWT 做一些权限操作，并检测 热力图 此时是否可用，不可用就会报出 /keyvisual/heatmaps error.keyvisual.service_stopped。 – from --> https://github.com/pingcap/tidb-dashboard/blob/d02b6af853a3cac31c7a4c031347b8f6f9be9732/pkg/keyvisual/service.go#L112 [image] 随后，通过 api --> http://{pdAdd…

看研发已经有介入排查了，大家可以关注这个 Issue --> https://github.com/pingcap/tispark/issues/2311

首先，功能层面，Lease Read 是 ReadIndex 的一种优化，当 leader 没有租约的时候，还需要通过 ReadIndex 确认每个 Region 的 Leader 位置。应该是二者均用。 from - -> https://pingcap.com/zh/blog/lease-read [image] 其次，时间层面，2016 年 11 月 25 日 lease read 相关 PR 就被合进 TiKV 了。也就是说 TiKV 1.0 其实就有这个优化了。 from - -> https://github.com/tikv/tikv/pull/13…

from --> https://docs.pingcap.com/zh/tidb/stable/check-before-deployment#在-tikv-部署目标机器上添加数据盘-ext4-文件系统挂载参数 [image]

首先，不是 BUG tiup dm 表示 dm deploy tool，DM 本身只有 dm-master 和 dm-worker 组件 [image] 其次，tiup dm 是给 dm 定制了一个 binary 工具，所以不是 v6.0.0 [image] [image] 最后，对于 “tiup dm 命名容易造成误解” 的问题，已经反馈给内部，会尽快找出更合理的解决办法。

这个报错是 tikv 返回的，可以看下对应时间点有哪些报错，反追 BR 行为。 目前信息只能 get 到 BR 发给 tikv 命令，导致 cop 线程池处理超时报错。 [image] [image]

First： Dashboard 信息来自何方？ Answer: Dashboard 中可视化的信息来自 TiDB 的 CLUSTER_HARDWARE 表；从 func FillFromClusterHardwareTable 得到 disk 信息 并在 func expandDisksItems 与 IP 信息关联，及按组件分类 [image] [image] Second： 怎么算的磁盘使用率？ Answer: used / total 并取 小数点 后三位 ，from --> https://github.com/pingcap/tidb-dashboard/blob/d…