打卡合影

是不是刚刚扩容或者安装的，需要时间数据均衡呢

计数项:region_id region_id 汇总 924 18 1276 40 1776 2 4005 16 4029 42 5149 84 5153 60 5753 158 6629 2 6633 2 6773 116 6825 4 6833 56 6893 2 (空白) 总计 602 可以看一下次数比较高的region 是不是请求时间太多了

juicefs+tikv 第一次看到这么玩，感觉很好玩

那现在可能已经超过GC 时间了吧，现在已经废了，删除重开吧。监控的之前没有搞过其他的，自己写shell 发报警，主要是用： curl -X GET http://127.0.0.1:8300/api/v2/changefeeds?state=normal 这个来解析，文档在 https://docs.pingcap.com/zh/tidb/stable/ticdc-open-api-v2/#查询同步任务列表 希望能够帮到你

抽奖还有机会吗

你的checkpoint point 时间怎么能是2024年9月呢

Tidb 负责解析sql ，,tipd 负责保存元数据，tikv 负责数据存储，索引和数据均保存在tikv 中，tidb 中不保存数据的

厉害，这边建议导入数据导入tidb 做可视化

感觉你的需求是 你是不想同步row，而想同步 sql（或者单sql 对应的row），类似mysql cdc 的 Statement 模式。 tikv 作为最后的存储，单位是行级别的，查看文档也没有事务ID相关描述，所以比较难拿到你说的。 另外你拿到以后再操作，个人愚见是危险的，tidb cdc 出来的数据是有序的，你拿到单个事务的数据再去处理可能导致你的执行过程与主表不一致，最终导致数据不一致。

【2025 年，你有新场景、新系统、升级的规划吗？】 实时计算 【TiDB 路线图和你当下需求的契合度】 50% 【对 TiDB 的产品迭代有哪些期待？】 物化视图，不限数据量的事务 【期待的新特性预计在哪些场景需要用到？重要性如何？】 实时计算，数据分析

https://docs.pingcap.com/zh/tidb/stable/tso/#tidb-中的-timestamp-oracle-tso 我的理解哈， TSO由两部分组成，一个是时间戳，毫秒级别。一个是逻辑时间，是表示一毫秒内的时间。比如你一次执行两条SQL，物理时间一样，但是两个事件发生肯定有先后之分，逻辑时间就是用来区分其先后顺序

我很好奇你的需求场景是怎么样的

B站大学可以看看，挺多视频的。数据开发现在也很卷，不过现在好像啥都很卷，哈哈哈

https://docs.pingcap.com/zh/tidb/stable/mysql-schema/#ddl-相关系统表 参考文档

我看了一下，可以有两个思路：1. 监控全库全表cdc，这个需要过滤所有非ddl 数据。2监控mysql.tidb_ddl_history 这一张表，不过我写的tikv-reader 对json 解析没有解析好 总体来看 单纯监控ddl ，可以使用方法2 ，我测试了一下没有特别的问题。 本来想写个文章水水积分呢，看来没戏了

试试HASH 分区看可以满足你的要求不，分区数给大一点

是关于tidb 吗，我有建议，下载最新tidb 文档，然后看一遍，有问题找文档，慢慢，基本可以记住大致的内容，也可知道有东西在哪里找。然后就是上手实践。再写代码，看代码，看底层实现，祝好运

o,哈哈哈，是滴，这个我给你瞧瞧哈