有没有打过标签？ 然后，可以检查下region 的分布情况

不太行吧，必须是国家规定的哪些才可以的

去 PD Dashboard 看看热点流量

事务是通过 tidb 实现的，tikv 是完成持久化的结果。 ticdc 是通过 capture Data change Event 实现数据变化过程的记录，和事务没直接关系。 记录是结果，数据变化的结果，比如，A行，B 列， 100 → 10 …

升级版本应该是一个好的选择，但是如果很稳定，估计不会升了 这个版本很古老了… 那个时候 tiflash 还不是那么稳

阿里云上那有什么本地盘，是云盘吧 资源规划的时候，没有做分区么？不同分区的云盘，才能保障数据的高可用了… 这就很扎心了

region miss 意味着逻辑上的表就是损坏的，可能无法读取，也无法写入。 先要进行修复了，要么恢复 region 的状态，可能会丢失数据。 要么重建表，将数据恢复进去。 region 缺失对于数据而言，是很大的问题了，3副本就是为了避免这个问题的发生。 如果有机会的话，请分享下 region miss 的过程…

你可以查下这些没有leader region 的表，看看表数据是否正常 然后这些情况是怎么发生的？可以说说么

好的坏的，是否有日志可以查阅？看看具体的情况才能更好的分析了

【2025 年，你有新场景、新系统、升级的规划吗？】 直接上8.5.x 了 【TiDB 路线图和你当下需求的契合度】 要等到GA，也只能看新的版本了 【对 TiDB 的产品迭代有哪些期待？】 MVCC 版本的优化，还有 TIDB 事务限制的特性，很期待

这 EOL 的时间更久了，YUM 能找到源么

这是什么 OS

This platform does not support both privilege separation and compression 看起来是不支持

可以看下这段话，patch 是用来打补丁的。没什么影响，可以通过观察 cdc 的日志，判断是新的架构，还是旧的

centos 8 → centos stream 8.x ，跑下来稳定么？ [image]

需要做 POC，一般会对比 centos 7.9 的使用效果了

org.apache.hadoop.hive.metastore.api.MetaException: Version information not found in metastore. 看起来是兼容性的问题，message:Version information not found in metastore. 换个新 hive 的版本试试 这些帖子可以参考下：

数据太大，小心事务问题… 理论上，数据很大，那么这些数据会先在内存中，事务提交了才会落盘，这个过程会比较吃内存资源了

不用担心这个问题，因为 tidb 是有 cluster id 的，这个是唯一标识 搭建的两个集群的标识是不一样的，所以 TICDC 去捕获数据的时候，会带有不同集群的标识。这个原理和 Mysql 双主同步类似 双向复制的集群不具备检测写冲突的功能，写冲突将会导致未定义问题。你需要在业务层面保证不出现写冲突。 你要关注文档中的这句话，只指的两个集群，不能同时写入同一条数据，数据库是没办法知道的