那这个id应该和原来的mysql表保持一致吧？ 我听你的意思是这块已经不一致了？成了mysql和tidb各自算自己的递增id了？ 如果说已经不一致了，那我觉得反而好处理了，重设一下这个表的自增id，大到不冲突就好了。反正也没有办法和原来的mysql做数据溯源了。 更好的办法还是从上游重新导入一遍，如果是从mysql迁移的，当初没考虑到溯源，随着时间推移查同步错误的难度会越来越大。可能同步错了也很难看出来。

不用搞的太麻烦，直接AUTO_ID_CACHE=1，这样换tidb 节点也是递增的。

我看了一圈，我感觉你的客户要的东西非常明确，就是双活。 北京，海南隔这么远，搞一个集群不现实。 2个集群，双活，双向复制，这就是他要的，你一直不给，他就一直给你上强度，提要求。 我劝你还是直接从了，或者直接看看下面这个文档，从双向复制有使用限制的场景看起，给客户介绍一下。相互上上强度，这个问题才好解决。 不然双方预期差距太大了，怎么都谈不拢。 https://docs.pingcap.com/zh/tidb/stable/ticdc-bidirectional-replication#ticdc-双向复制

感觉是个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配置发出来看看，这块每个云的方式还真就是都有些细微的差距，需要多试几次的，注意有些信息是保密的。要遮掩一下。