楼上说的太对了。s3的兼容性是个谜，不测根本不知道。

看看这个

根目录下找找看，endpoint cos前面那一串是不需要的。 有可能是把前面那一串当成路径用了。这样的话有可能在你的根目录上。

需要吧，好像是每次启动的时候会去读这些硬件配置。已经启动的应该不会动态的修改。

[图片] uptime都能跌0，再跳回去。就说明pd没挂，但是因为什么原因连不上了。uptime这个监控数据都收不到了。 重点查查网络。

发一下监控图，这是另一个问题了。

没有影响。 要么是运行时间超过 https://docs.pingcap.com/zh/tidb/stable/system-variables#wait_timeout 这个参数了，被自动取消了sql的执行。 要么是客户端执行sql时间长了，ctrl+c了，或者点小红方块取消了。 就会报这个错。

日志里面有什么内容？看看多少会有点线索。 这个你也看看吧，可能对你有帮助。

[2024/12/20 11:51:39.799 +08:00] [INFO] [main.go:82] [“dump data successfully, dumpling will exit now”] 不能更好了。

在 TiDB 中，“Region Exception occurred to store id 5, mine 4” 这样的错误信息通常表示在集群中某个 Region 的副本在不同的存储节点（store）之间出现了不一致或异常。这种情况可能是由于网络分区、节点故障或其他原因导致的。 在 TiDB 集群中，数据被分成多个 Region，每个 Region 有多个副本分布在不同的 TiKV 节点上。PD 组件负责管理这些 Region 的分布和调度。当某个 Region 的副本在不同的 TiKV 节点之间出现不一致时，可能会导致 SQL 查询失败或性能下降。 具体到错误信息 “Region …

说说之前对架构做了什么改动？这是取到了cluster id但是发现和自己的不一致。 一个tiup管理两个集群，把b集群的pd扩容到a集群上，把原来a集群的pd给覆盖掉了？

你pd的地址配置的对嘛？怎么会获取不到cluster id呢？ https://docs.pingcap.com/zh/tidb/stable/pd-control#cluster 这个功能太基础，不应该有问题。 完整的日志提供一下。

务必不要错过置顶帖子中的 TiDBer 唠嗑茶话会 这个每周回帖参与就有积分可以拿

重点观察一下连不上的tidb节点是不是都是和tikv混布了。我感觉这个可能对tidb的稳定性影响最大。

恭喜圆满解决，我看你问了好几天了。

你这32g的机器我想不通，为啥14g的时候就要开始杀掉一个进程了。 除非是有其他的进程加起来超过18g了。而14g已经是整体占的最多的一个进程了。 整个机器的内存占比监控有吗？

首先楼上说的对，这个是预估的容量，不是准确占用。 然后看具体情况吧，假如一个表3个字段，你排列组合可以建7条索引。 这种极端情况下，索引比表的数据多也不奇怪吧。 重点分析那个表的索引占比高。找出挑的来看看具体是什么情况。

看来还真是硬件那个地方有问题。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。