https://docs.pingcap.com/zh/tidb/stable/tiup-cluster-topology-reference#monitoring_servers [image]

混合部署？

你已经设置了 [img_v3_02fm_9e7d94c5-64e4-4a1d-a2e9-78ff16f0ab8g]

tc.spec.timezone 会自动设置到每个 component 的 env 里，比如 tidb 在这里设置 容器运行时会用 env 设置 timezone [img_v3_02a1_72bc87b7-264e-4102-9b82-414c0bec80eg]

现在 status 端口只提供 meta 类的， mysql 兼容 mysql 不做估计 tidb 也不会去做

这 “索引” 两个字容易引起歧义 ，现在的 tiflash 就是类似的列存 “索引”

重装 operator 用 v1 CRD，这是管理组件不影响 tidb 集群

直接卸了用 v1 重装

ru 类似于信用卡每秒有 2w5 的额度，如果第 1s 就用掉了 25w，接下去 9s 都处于欠费状态

这点和 mysql 兼容

TSO的时间窗口分配模式 这个没问题 PD 只管分配 tso TiDB 负责写入 tso 怎么保证TSO的全局唯一递增，多个TiDB Server之间不会出现逆序的情况 上面关于事务的说明已经解答了

需要先明白乐观和悲观的区别，理解 TiDB 两阶段提交，题主的问题我理解只可能发生在乐观事务情况，对于悲观事务在 prewrite 阶段就会检查 ts 进入悲观锁等待 上面很多人提到了，commit 时会需要向 PD 获取一次 tso，此时 prewrite 已经过了，其他事务不应该能抢先 prewrite 而会进入 backoff retry。 反之如果其他事务先于当前事务 prewrite 成功，则当前事务 prewrite 应该 backoff retry 具体可以看一些官网介绍比如 TiDB 最佳实践系列（三）乐观锁事务 | PingCAP [image] 另外 5.0 针对…

扩缩容是最简单的，另外可参考 https://mp.weixin.qq.com/s/lpURNRwqL7YzqQmVCB88Tw

A 事务提交时需要检查数据库里对应数据 commit ts，如果比它还小说明已经有其他事务提前提交了

TiCDC 写入的数据带有标签，同步时会过滤

没搜到 mysql 语法支持，要么找找 mysql 工具

数据变化频繁，若数据特征一致通常执行计划不会有问题，若担心统计信息收集不及时，用 hint 或 bind 固定执行计划

design doc: tidb/docs/design/2022-11-25-global-resource-control.md at master · pingcap/tidb · GitHub 虽然不是很清楚具体实现细节，但有一点可能可以解释上面的一些问题比如尖刺： TiDB / TiKV 是分布式架构，和 OB 的实现上不太一样，TiDB 使用一个统一的 RU 来定义资源使用上限，这样涉及到一个问题，假如集群有 2 个 TiDB 节点，RU 配置 1000，那分配到每个 TiDB 节点上的 RU 应该是多少才合适？ 这里 design 文档中有具体的描述（虽然看不太懂），既有 …