-s选项接受多个以逗号分隔的store_id，并使用-r参数来指定包含的 Region。如果要对某一个 store 上的全部 Region 都执行这个操作，可简单指定–all-regions 你强制下线的store，用 --all-regions 了吗？是不是还有2副本丢失的没修复？ 清理失败的region并不是删掉了，是把region补齐。tidb的所有region的范围首尾相连，最终变成一个完整的从最小到最大的key的区间。不会有空洞的。https://docs.pingcap.com/zh/tidb/stable/tikv-control/#强制-region-从多副本失败状态恢复服…

看看tikv的 grpc请求，哪个种类的多。也看看 tikv 的日志，看看在输出什么。

5.0以前 tidbbinlog 是个方案，5.0以后这个就不怎么支持了。

说的跟真的似的，tidb有binlog吗？我怎么不知道？谁来给我科普下，或者辟个谣。

用 dumpling和lightning 导一下全量，记下来 tso，增量用 cdc https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-data-source/#表库重命名

朋友们当下你们是否也会遇到这样的困境？ 目前确实采购不来新机器 面对资源缺口，你们会倾向于上云吗，还是其他方案？ 我们就是云厂商，用户还是会用的，就是会更精细化一些 上云过程中，你最担心的是成本、稳定性，还是迁移风险 ？ 成本，稳定性是基本的，迁移是上云必须要经历的，拍板上云的老板就关注成本就行了

很棒！ 不过我有个疑问，我过去理解的版本规则，最后一位版本号是bugfix。最后一位越大版本越稳定。 现在看好像是有新功能加入（比如说按列授权）。是我之前理解的不对？还是版本规则有调整？

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

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 的文档不足够详细，我期望能快速生成一个模板例子，我改改库的账号密码就能用，然后可选的参数以及默认值都列出来，想改什么就改什么。