你说对了，写这段的是个超级大牛，能看懂这段的也是大牛哈哈

Hello， 问题一：这个应该跟 DDL owner 有关系，DDL owner 应该是在 134 那个 tidb 上，所以其他 tidb 执行的 DDL 语句，最后会让这个 DDL owner 去执行。 问题二：v5.4.3 的 PD 地址是通过 PD members 获取的 https://github.com/pingcap/tidb/blob/v5.4.3/store/driver/tikv_driver.go#L232-L247 可以用 pd-ctl member 确认一下旧 PD 是否已经下线。

你的副本数设置是 1，https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file#max-replicas 正常情况下，region 对应的 peers 个数应该是1 。 之所以出现 2 可能是你在测试过程中触发了热点调度之类的，在搬迁数据过程中，就会出现多个 peer 的现象。搬也就是需要从 tikv1 搬迁到 tikv2 时，会先在 tikv2 上拷贝一个副本（peer）出来，迁完毕后，再把 tikv1 上的那个副本删除。所以数据搬迁完毕后 region 的 peer 个数会恢复到 1. 想要知道是否有调度生成，可以通过看…

Hello，txn 模式访问 tikv 时，region 相关处理如下： txn 向 PD 根据 key 获取 region 的对应信息 txn 向对应 TiKV 带着 region 元信息（如版本信息）发送请求 TiKV 收到请求后，检查 region 信息是否对上，这个过程主要是用来保证 tikv 中的对应 region 没有发生过变更，如 split, merge. TiKV 开始处理请求，在拿到 snapshot 后处理咱们这个 key 时，发现 key 已经不在这个 region 了 确实如你所说，在 3 以后，这个 region 可能是发生过变更，比如 split, 就会导致…

会的，compaction 完后会把旧的 sst 删掉的

Hello，出现这种情况有一种场景如下。 有一个很大的表，假设垮了 10 个 region 通过 delete 的方式陆陆续续开始删除大量数据 PD 发现 region 1 和 region 2 很小，发起 merge region1,region2 在 merge 过程中，需要先把 region 1,region2 的副本迁移到一起，迁移过程中，因为是直接写 sst 文件到目标节点，产生了小 sst 文件 merge region 1， region2, 成功，这个时候可以看到 merge 后的 region 的 mvcc properties 里面有小 sst 文件 出现 同样的道理，…

嗯嗯，另外特别注意的是，监控节点不要部署在断网那台机器上，会导致其他实例无法上报监控信息导致监控不准确。

Hello，因为问题前面断网我看是一会断这台，恢复，断另一台，再恢复，这种情况下分析引入条件比较多，分析起来也比较复杂，而且也不是特别贴近我们的实际应用场景。所以我们这边暂不分析。 我们只说三副本情况下，能够保证剩余幅本数 >=2 的情况（即保证多数副本可用的情况），如果忽然有一台(机房)断网了，这边主要涉及两个地方重新选主： 如果切掉的正好是 pd-leader 所在机器，则 PD 需要重新选主，这个时间大概是 15 s 左右能够完成。 对于那些 leader 在断网上的 region, 剩下的两个副本会发现自己没有 leader, 重新开始选举。其中 发现自己没有 leader 的…

问题一 mysql> select * from test.sbtest7;ERROR 9012 (HY000): TiFlash server timeout 因为只添加了一个 tiflash 副本，因为断网的那台机器上的 tiflash region 连不上，所以 server timeout 符合预期，想要规避这种现象，可以添加两个 tiflash 副本进行验证。 问题 二 select /*+ READ_FROM_STORAGE(TIKV[sbtest7]]) */ * from test.sbtest7;ERROR 9005 (HY000): Region is unavai…

在 tikv-details 监控面板上，每个 scheduler 也就是事务层 API 的监控中，都有一个 scheduler latch wait duration 面板，这个等待时间越长，说明同 key 争用越严重。 [bGd6u0EjIP] [QPFAsxGobF]

tikv 中的 latch 主要用于 tikv 事务层的并发控制。具体加锁的对象是 tikv 事务请求中的 key 对象，防止多个并发同时对 同一个 key 进行操作。 想要快速了解，可以通过阅读本文件末的test 案例来对这个 latch 进行简单的了解。 tikv 本身对外支持 ACID 的事务模型，所有的事务接口，都要确保其原子性 tikv 的事务实现基于底层的 raftstore，目前 raftstore 能提供的原子性操作只有两种： snapshot 级别读取 批量写入 tikv 需要基于以上接口来实现事务接口的原子性，而大部分事务接口，都需要： 读，检查可行性 批量…

4.0 版本 region-properties 详解： num-files: 本 region 涉及的 SST 文件个数 num-entries: 本 region 范围内， 在 rocksdb 内的 kv 数量，包括 tombstone, 不去重 。为 rocksdb 直接计算所得。 num-delete: （num-entries-mvcc.num_versions）,本 region 范围内，在 rocksdb 内的 tombstone key 的数量, 该数据量越大，说明当前服务需要进行 compaction 了。 mvcc.* 主要记录 tikv 层的 mv…

我要挑战

Hello，我们 dashboard 支持日志的审计过滤和操作功能，不知能否满足您的需求，相关文档：https://docs.pingcap.com/zh/tidb/v4.0/dashboard-log-search

感谢！4.0 GA 目前已经支持下推计算 cache 功能可以解决部分这个问题。 另外，我们也有一个readonly 表的需求设计应该也能满足您的需求

hi, 目前 4.0 GA 以下两个命令可以满足您的需求： show processlist + kill tidb {connID} 相关文档： show processlist kill tidb {connID}

TiDB 4.0 底层做了逆序索引的支持与优化，目前速度比顺序 Scan 慢一些，通常情况下慢 20%。

感谢，和事务这边研发沟通了一下，这个东西的说明确实是我们目前所缺失的，建议加入我们的 Transaction-SIG ： 加入及时沟通平台，与我们事务的一线研发面对面沟通一下， 加入方式： 加入 Slack 加入事务聊天群 - transaction-sig @csnever

问题一，想要参与开发并获得更多一些帮助，可以加入我们 事务 SIG，内有加入 SIG 交流平台的方式。 问题二：两者都可以： 直接忽略，后面读写遇到锁时，可以再根据 primary key 上事务的状态，决定如何清锁 发起 rollback, 直接清锁就可以 问题三、四：同问题一的处理方式。 目前 go-client 虽然跟 TiDB 脱离比较久，但是使用方式依旧可以去参考 TiDB 的相关源代码。