通过pd-ctl修改max-replicas 为 1，就改为单副本了，操作如下： tiup ctl:v8.5.0 pd -u PDIP:2379 -i config set max-replicas 1

好的，感谢

排查了，是因为磁盘的问题，修复后扩容上去的

leader-schedule-limit是4，placement policy是默认策略，store weigh都是1这些都没变

store-4和store-7在监控上看都是11G，查看tikv的data_dir占用空间都是17G，这个问题节点上监控是672MB，data_dir占用空间是3.5G。基本是对的上的

[image] [image] 在kv的数据目录下，看到正常节点的db大小为1.1G，异常节点的db大小才361M

这个是store use的表达式： [image] 这个是region size: [image]

现在region的健康度如下，感觉也没啥问题。 [image]

这么说的话，region的数量不能确认副本数据是否完全同步过去是吧，那是否能确认该节点还没缺少数据副本呢，那麻烦问一下怎么确定3个节点是相同数据副本呢。

嗯嗯，从region的数量可以确定副本数相同是吧。但是副本数相同这里存储占用差别那么大呢。 [image]

这个4.97的服务器的磁盘是小一些的。我是这么理解的，现在就3个kv节点，是3副本，3个副本是分摊到不同kv上的，那么即使配置有些差异，应该也不影响副本数，数据应该是一样的吧

目前是过去差不多12个小时了，基本上没有平衡数据，主要是3副本少了一个副本了，感觉是无法自动补齐一个副本呢

enable_tls: true，这个修改成true的话，是不是整个集群都调用客户端都要修改为ssl的方式

嗯嗯，查看cdc列表中是没了，但是看service_gc_safe_points还是有。 执行完：tiup cdc:v6.5.3 cli --pd=http://172.16.105.24:2379 unsafe reset后再查看service_gc_safe_points就没了；然后查看gc leader就正常的日志了。 但是不知道为什么会出现这种情况。

考虑一下是否是网络连不上、防火墙开启、或者机器宕机了。

嗯嗯，现在是集群环境下的v6.5.0还是包括delete的语句，单机环境部不包含delete语句。 请看我得回复说明。

嗯嗯，还有更大的彩蛋，我们测试部部署的v6.5.0使用的是单机版的部署方式，我现在测试是部署的一个简单的集群。使用相同库名，相同表结构，相同kafka版本，创建changefeed使用相同的toml配置文件结果出来的结果不一样。 结果如下： 单机版：执行replace语句数据不存在会同步出去insert事件的数据，如果对应的数据存在则同步update事件数据。 简单集群：执行replace语句数据不存在会同步出去insert事件的数据，如果对应的数据存在则先同步delete事件数据再同步insert事件数据。 找了好多遍没找到啥原因。 [image] [image] [ima…

从慢查询中可以看到很多相关更新该表的操作，但是这些都是数据库自己的更新吧，从慢sql的执行计划中可以看到，花的时间都是在lock_keys上。 [image]

嗯嗯，感觉是这种问题。但是这种除了升级对应的版本来解决外还能怎么解决呢？split region是否可以减少该问题产生呢？