那你试试缩容再扩容下看看吧，感觉像误删了还是其他情况，或者把其他地方的文件目录迁移过去

stop会把目录干没这我真第一次见，tip cluster display还能看到prometheus这几项么，如果没有的话可能是有人误缩容了吧，再给扩容回来，如果有的话你看看prometheus的目录还有备份没，有的话挪过来一份再启动

这个目录有么，如果没有的话感觉像是走错配置文件了，是不是有好几个版本的tiup在不同用户上

lighting还原的时候可以做路由配置 [image] 这种，不知道能不能满足你的需求

那第一个就可以用我说的那种方法了，先全量再增量，我一般都是这么同步 第二个问题不同路径也会有这个问题么，我到没有测试过，我以前都是放到一台机子的不同端口，不同路径，没有出现过问题，比如扩容dm-worker的时候配置dir就是dm-8262,dm-8263

如果出现的很频繁，可以在cdc做个抓包，看下什么命令 然后截取下两个备库的通用日志，对比一下，看那个没同步，是否有deadlock出现导致命令没执行等，是否有执行出错的语句，查看下对应时间的cdc日志看看

问题一：可以采用dumpling+ligthing全量同步，然后再根据对应的时间节点用dm进行增量同步，这样可控性高点，lighting配置的时候就可以正常配置想要的模式了 dm配置的时候也是可以指定的，详见文章：https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full [image] 问题二：不同的worker可以放在同一台机器上，不过扩容的时候要指定不同的端口路径等，资源够最好分着放

你看机器上还有9093端口的监听没有，这种一般是有system启动的node_exporter等把端口占用了，把对应的关掉就可以起来了

pd_scheduler_store_status{tidb_cluster=“$tidb_cluster”, store=~“$store”, instance=“$instance”, type=“region_size”} store_region_size应该不是实际的磁盘空间大小，我这里的一个集群每个tikv磁盘占用是400G，store_region_size是2T,感觉是5倍多一点，和你这个差不多

https://docs.pingcap.com/zh/tidb/stable/sql-statement-trace#trace 这个应该能满足

参加云数据库 TiDB 免费试用活动

explain analyze试下呢，把执行计划发下，看是否和dashboard中一样

用dumpling+lightning的路由会不会更好一点

,这里确实没注意到，感觉这个库名的这个注意放在最外层更好点，这里感觉像read_from_storage的一个特性，前面没有说明，给我的感觉像是只指定表名就可以了

开工大吉，升职加薪，财富自由

内蒙：享受在草原上策马扬鞭的快意

这个有用haproxy传透之类的么，好像是个bug，应该不是load data导致的 https://github.com/pingcap/tidb/issues/31063 看bug来说只是日志级别的问题，应该不会影响loda data的执行

表结构一样是把数据放到原表，还是原库更改表明，如果是后者就是dumpling+lightning路由方式

这个启动顺序只是说你启动一整套集群的正常启动顺序，每个组件，每个节点都可以单独启动，4也可以改成tiup 或者试试binlogctl https://docs.pingcap.com/zh/tidb/stable/binlog-control#binlogctl-工具