看监控截图，感觉网络带宽最大可以到 100MB，是不是千兆网络？

TiDB 日志只是现象，说明 TiDB 从 PD 获取 schema version 失败。但是为啥子失败，还要看看 TiDB Sever 所在节点的服务器状态是否正常、CPU、内存、IO、网络 都要查一下如果没问题，混合部署且资源配置低情况很容易抢占资源的，再说别的。

[image] TiDB POD 扩容几个新的在不同物理机器上面，有同样的问题吗？

这个问题可能有其他原因，不确定是否已知 bug，可以看一下相关的 Release note。 https://docs.pingcap.com/zh/tidb/stable/release-6.5.2 建议升级到 v6.5.10，TiDB 数据库一般只会在最后的 10 这里修复 bug，不会引入新特性的问题。 [image]

https://docs.pingcap.com/zh/tidb/stable/performance-tuning-methods 这个看过吗？TiDB 官网上面有很多这样的材料，可以根据你的 load 场景优化优化参数的，或者分析一下线程池的瓶颈问题。

懂了～ 其实有几部分，prometheus 这边的历史数据会通过独立账号的进行访问提供监控数据库的，其他部分实时性数据会通过 tidb、pd、tikv 的 promtheus 的 api 及时 pull 过来。 [image]

展开描述一下？是 Prometheus 开启了什么基础验证？ 是 SSL 还是 Security verify 这个？

Seatunnel 配置管道任务从 TiDB 4.0 读取后，然后通过 JDBC 分别写入到 Doris 和 TiDB 8.1 吗？ JDBC 配置这块有没有按照这个优化优化？ https://docs.pingcap.com/zh/tidb/stable/dev-guide-sample-application-java-jdbc

不能直接用，可以在 ceph 上面创建文件系统，然后指向文件系统按照 local storage 方式来用。具体 CEPH 配置可以在 ceph 官网或者技术网站上面找一下哈。https://www.jianshu.com/p/096cc18f051a

@TiDBer_h63MwG4e 可以排查一下 TiDB 上层 proxy 这边的连接到 TiDB 的配置方法，比如长连接没有配置探活机制，导致连接超时。

[image] 在 client 端执行 show variables like ‘%timeout%’; 看一下参数配置情况，目前默认参数没有 10min 限制，需要再确认一下呢

可以注释试一下

在看一下对应的 cluster 的 yaml 的配置文件里面有吗？

试试这个 prune 命令可以清理已经 scale-out 的节点。 https://docs.pingcap.com/zh/tidb/v7.1/tiup-component-cluster-prune

不用纠结当前单个任务的写入速度的问题，因为 Oracle 和 TiDB 上下游就是两种架构的数据库，另外 DataX 本身对于异构数据库的迁移都是按照 Batchsize 和 Parallel 来优化同步速度。可以参考一下 DataX 的项目的文档，对于这张大表根据 SplitPK 或者 Where 命令进行多任务拆分，增加下游 TiDB 的并发处理读写请求的速度。这样下游 TiDB 集群就不是单任务单并发处理，体验一下分布式数据库并行处理能力。

TiDB 的 TiKV、TiFlash、PD 的组件以来 IO 建议本地 SSD 盘，TiDB 的组件网络 SSD 盘即可。TiDB 在存储架构采用 LSM-tree 架构属于密集型 IO 应用架构，所以 Nvme 直通盘最理想。 Tips：业务场景处理请求以及容灾需求均有差异，建议按照生产业务优先级以及处理响应延迟敏感度选择适合的磁盘选型。

可以的哈

备份binding执行计划 mysql -uroot -h127.0.0.1 -P4000 -p -NBe "select * mysql.bind_info\G" > /home/db/tidb/bing_info$(date +"%m%d").txt 反向创建binding执行计划 mysql -uroot -h127.0.0.1 -P4000 -p -NBe "SELECT concat('use ', default_db,';', 'CREATE GLOBAL BINDING for ', original_sql ,' using ', bind_sql ,';') from …

报错来看还是和聚簇索引 和 Shard_row_id_bits 不能共同支持的原因，可以参考另外一个帖子了解一下报错问题。lightning local模式数据迁移fail to split region - #3，来自 Lucien-卢西恩 可以使用 Lightning 导入成功的情况，看一下下游的 Table 的 schema 以及 show table region 的命令查看当前表数据是否已经 sharding 来判断是否已经生效。