感觉是个bug。最好是有个cpu的profiling，更容易定位问题。 github有些近似的issue描述，但最后都没有后续了。 https://github.com/tikv/client-go/issues/1518

threads 这个参数设置了吗？是多少？ 感觉yscb load并发不够。往大了调，起码 这个不应该的。

小红书流量暴涨，能扛下来确实牛。

s3首选，nfs次选。 我觉得报错的问题定位应该是没错的，还是需要细心一点，多尝试一下，应该是某台机器目录里面是缺文件的。

你的理解可能有点问题。所有的tikv都掉线是没法从unsafe recovery恢复的，只能从br备份恢复。 在3副本的情况下，丢失1个副本，pd会调度其他还有空间的tikv补副本回到3副本的状态，这个不需要人工干预。 但是丢失2个副本，则会造成raft组已经不能保证多数派在线，会导致集群不可用。这个时候没法做到无损恢复，必须人工干预。这个人工干预的方法就是unsafe recovery。丢失的数据就是leader 到follower之间的这一小段。 所以当你的tikv全部掉线，unsafe recovery是没有办法完成的。你起码要保证1个副本能用，才能用unsafe recover…

设计文档在这里

好像是这个，我对这个不熟，不是非常确定。

我不信你看了课程没有任何疑问。有疑问就可以问的。 如果课程也不看就去考，那只考一次的积分可能有了也是不够用的。

我之前用的metabase，也没什么问题，就当mysql用。

defaultRegion就是us-east-1。 当Region没写的时候，就把us-east-1设置为region。 所以这里的报错才是这样。 那这样的话，region还必须要有个值。 这个还得让你们的s3提供方，想想办法。

不能，这样装的haproxy的版本就是带bug的。当初坑了很久才发现是haproxy的问题。 现象是haproxy会拿着死连接不释放。必须换haproxy的版本，手动编译了一个才解决。现象和他这个描述类似。 不过本贴这个问题后面说了换了tiproxy也不能解决。这个就不知道是什么原因了。

这个命令运行的时候报什么错呢？

By not providing “Findlz4.cmake” in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by “lz4”, but CMake did not find one. 我看报错提示就是缺这个文件。如果编译的时候能找到Findlz4.cmake这个文件，那么无非是调整这个文件里面的参数，就应该能让编译器找到lz4的包。 而这个Findlz4.cmake文件的内容，我觉得就照搬rocksdb里面的这个试试看。 不过，我不…

大概率是负载均衡LB的问题。 LB用的是haproxy? ubuntu20 apt直接装的？这个方式安装的haproxy是明确的有bug。会卡死连接。

没有就不填。 有些云上的s3，region直接就是写在url里面的，也等于没有region，就不填这个参数就好了。 我猜你试过不填的情况，应该是不填也没成功。 不妨直接把s3配置发出来看看，这块每个云的方式还真就是都有些细微的差距，需要多试几次的，注意有些信息是保密的。要遮掩一下。

看这个issue是一个go版本的bug导致的这个报错。 用tidb_version函数看7.5.4这个版本编译的时候go的版本是多少。 大于等于1.23.2就行 https://docs.pingcap.com/zh/tidb/stable/tidb-functions#tidb_version GoVersion: go1.21.10

不知道你这个rocksdb用的是那个版本的。 但是rocksdb的库里面应该是有个Findlz4.cmake文件的。

你这个理解是没问题的。 我理解catch-up这件事是每个region自己的事。除非整个store的region都是leader。否则store级的catch-up这是个挺理想化的事。