方便使用transactionKVClient吗

那请问一下老哥，如果把tikv调整配置bytes-per-sync=0，raft日志直接落盘，这样在断电的时候是不是就好恢复了

嗐，属实有点头疼

集群只有一个TiKV节点的话，如果你已经执行了unsafe remove，那就只能重建这个TiKV节点了。如果是因为sst受损导致节点起不来，可以尝试使用tikv-ctl 的bad-sst命令找到出问题的sst和相关的region，按照命令输出的suggestion命令执行，TiKV会跳过这些sst和region

可以选择在一台TiKV节点上重建region试试。先关一个TiKV实例，在这个实例的机器上，执行 ./tikv-ctl --data-dir /data --config=/tikv.toml recreate-region -p {PD_ADDR} -r {region_id} 执行成功之后重启这个实例就可以了。

用tikv-ctl ldb -db=data/db repair修复试试

v6.3.0有修复

我在github上提了个Issue https://github.com/tikv/pd/issues/6647#issuecomment-1600434267 有个大佬提到在 https://github.com/tikv/pd/pull/5330 中进行了修复，看changes确实修复了报错。 v6.3.0解决了该问题

不定期重启不就不正常吗，关键这报错也不知道咋修啊，只是先停掉了pd的调度。

断电相关的用户反馈多吗 pd能正常提供服务，只是用tikv-ctl工具的时候，需要连pd，如果pd中间重启了，工具就失败了。 从报错日志上来看，感觉是pd的一个bug

最后采用了部署新pd集群，然后让tikv加入到新pd集群的方式。主要原因在于内部devops平台在做pd扩容时并不会像tiup和kubuctl那么流畅。理论上讲，我们自己用的devops也能做到pd扩容，只是扩容的细节不清楚，没办法进行适配

换了种方式，在已有pd-1上join要加进来的pd-2，pd-2能正常启动，但问题在于，这两个pd的日志中显示是不同的cluster，用pd-ctl查看也是各自属于各自的集群，这和预期并不相符

用TiKV做存储，上面封装一层业务逻辑和额外的检索引擎，是不是可行

谢谢回复，即使tiup管理了原来的集群并扩容了pd，新增的pd节点在内部的devops平台也不可见，对用户来说不太友好。还是尝试增加节点，然后用类似pd join或者etcd member add的方式操作下

pd扩容，不使用tiup和kubectl，需要注意哪些点呢？我们用的内部部署工具，在增加节点的时候可以为节点添加一些启动参数。我应该在启动参数里面加上什么呢？我有看到一个join参数，比如从pd-1扩容到三台节点，我在pd-2和pd-3中join了pd-1，实验结果显示pd-2和pd-3都启动到了一个新的cluster中，通过etcd工具查看member list，发现这个新的cluster包括pd-1 pd-2 和pd3-3，但pd-1实际上还是在原来的cluster中，所以pd集群内部并不能达成一致，而且因为交互时发现不在一个cluster而不断报错。我应该还需要注意哪些呢？kubectl…

tiup有办法连接到环境中已有的集群中吗？部署的时候不是用tiup部署的

我实验了一下，直接join的话，会生成一个新的cluster，新的cluster包括了join的节点，但并不是加入到了目标节点原来的cluster中

写个脚本，用tikv client的Iter方法可以scan tikv存储的kv

这个unsafe recover实际上是删除了不可用的节点，让剩余的节点重新分配region并提供服务。在单机的情况下并不适用。