你用你的龙虾做什么事情？表现如何？ 收邮件、分析报警 未来几个月你打算在哪方面去探索和龙虾的协作？ 自动发送给指定的人，替我值班。 你觉得你跟龙虾协作的过程中产生了哪些问题/哪些惊喜？ 问题：有时候显得特别笨，不是每次都能正确的处理问题。 惊喜：一些简单的报警就不需要开电脑了，也算是进步。

tikv 可以理解成从 负无穷到正无穷的 key 区间，划分成一个个的region。 tidb 在这个kv的上面构造表结构之类的。 每个表不同的前缀。 可以一个设置：每个表强行一个region。这样就相当于用表前缀为界限分割region

我看你的报错日志，只有一个 2730583.sst 丢了，另一个节点也是丢sst吗？看看另一个节点启动失败的原因。

主要是两阶段提交： [image] https://learn.pingcap.cn/learner/course/750002?utm_source=docs-cn-dev-guide

问题 1：在 TiDB 集群出现故障时，您最希望 TEM 的 AI 智能运维功能能够帮助您解决哪些具体问题？ 告诉我集群现在发生了什么，按照压力的规律，对比过往监控，看看哪个指标增加的更快。 问题 2：对于 TiDB 集群中的慢查询问题，您希望 TEM 的 AI 智能运维功能能够提供哪些具体的分析和优化能力？ 识别出慢查询，并且给出建议，即使说sql已经没得优化了，可以参考表结构建议加一些索引，或者sql拆一下，换个写法之类的，说不定业务方就是脑残，随意写了个垃圾sql呢。 问题 3：在日常运维工作中，您最希望 TEM 的 AI 智能运维功能能够自动化哪些巡检和监控任务？ 实时对比监…

其他选项都很正确，LSM tree 的删除是写入一个删除的key，然后等这个key和下面的key通过compact消消乐，最终就删掉了。

tidb 一个的话，挂掉就没了，两个能保证高可用。至于3个，没什么严格要求吧，就当2个就行了。

你现在用 TiDB 时，最卡业务、最费人力的问题是什么？ 看性能，比如说昨天一个抽数任务执行了10分钟，今天1小时。这是发生了什么。 如果加一个新功能就能少加班、少踩坑、少花钱，你最希望是什么？ 搞一个基线对比的功能，所有的监控都把7天前的或者1天前的基线贴在那里，哪一块有问题直接能看出来。 什么功能一旦上线，会让你更愿意升级 / 付费企业版？ 如果我能决定，我现在就想付费买企业版。

[image] 希望 TiDB 做大做强！走向世界！

携手奔赴下一个十年！

你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？ 从mysql 分库分表迁移到 TiDB的，用过 DM，也用过自研的，自研的好处是配置简单，DM 的配置略复杂。 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？ DM 的文档不足够详细，我期望能快速生成一个模板例子，我改改库的账号密码就能用，然后可选的参数以及默认值都列出来，想改什么就改什么。

压力太大了吧，扩容或者优化sql吧。

我理解不支持，但是这个确实是不错的功能，能降低不少tiflash的存储量。

[image] 这里是把 <1,Jack>,<2,Candy> 两个属于不同region、不同tikv的key按事务写入tikv。 首先是prewrite，在default cf 和 lock cf 写入数据，把要写入的变更按region分成2个grpc，分别发送给2个tikv。 两个tikv 分别在default cf中写入数据，lock cf 中写入锁。其中 tikv1 中的是主锁，tikv2的是从锁 提交时，tikv_client 首先给主锁所在的region发送grpc，在write cf中写入commit记录put<1_100,100>,删除lock cf 中的锁<1,(D,…

另外补充一下：这个报错如果返回给了客户端，客户端常用的访问 mysql 的那一套靠 durid 的封装没有抓到这个报错（也可能是我们程序写的挫），这会给客户端造成数据已成功写入的假象，建议这个错误至少能做个兼容处理，让客户端能感知到这个错误。 还有另一个错误客户端捕获不到：当事务超大，返回 out of memory 的时候，链接也没断开，我们一个程序会认为结果还没返回，就一直傻等着。这个问题不确定是程序导致的还是 tidb 自创的这些报错 jdbc 驱动无法拿到。

这是 tidb-server 报的错。

曾经的雨伞，没列出来！很实用！使用频率最高的当属充电头了，充电很快！偶尔笔记本没电应急也能用！

这个真是太棒了！读写热点问题会降低不少！