唉，看来高手都没在这边啊，pd的问题一直没能解决，不过我通过变通的方法最终成功的将数据导入了，版本为v5.0.1
先解释一下，让有相同问题的人也能得到帮助，我有生产tidb的两个库，先通过dumping想导出来，然后在新的tidb备份环境还原它，然而库的数据实在是大，一个库是500g一个库是800g，先导出小库500g的，然而为导出的时候dumping总是把tidb给搞挂掉，使用了rows和size限制，貌似没有鸟用，还说推荐呢，看来tidb的成熟度还要加强啊，唉，也可能我们的服务器配置不够吧，说实话，tidb看中的是他的横向扩展能力，简单易用，然而刚开始所要求的生产环境的tidb的配置，什么万兆网卡，什么ssd，什么64g内存，32核等等，晕了，这现有的生产系统也不那多资源啊，根本达不到，一度差点放弃。后来试用了一下，在比较一般的环境下tidb还是能跑的，只要不用它做在线业务库，当个历史库或者olap库应该可以吧。还好，我的目的比较明确，说实话，新接触tidb的人也应该都是用它来做历史库从库或者olap库吧，敢直接用生产的，要不是胆大，要不就是款爷。
闲话少说，这里也提个建议：希望tidb设计的时候能出单机版，或者内存版，也就是支持单机高cpu高内存高速ssd，做为联机在线交易使用，减少网络单的依赖，当然如果可以多机，那就支持光纤互联的那种，这样把联机的性能做到极致。然后olap就放低机器配置要求，允许低io与千兆网络集群环境使用，将其横向扩展做到极致，这样能充分满足人们对newSql的需求。
好了，下面进入正题：我用dumping实网导出失败，但在测试环境导出是没有问题的，因为测试环境数据量少，然后用tidb-lighting进行导入，然后用backend = "local"导入，官方推荐的，导入是成功了，但是，但是，居然select count() from xxx，居然是错的，与原库不同，真是大坑，这个见我另外一个贴子。count(主健)是对的，你说要tidb-lighting何用！！！后来还是使用backend = "tidb"纯sql的方式导入才正常，count()和count(主健)是一致的，但是这种方式就一个字：慢。
不过反正正式环境dumping导不出来，放弃这种导出导入了，改用br。测试了一下br导出，正式环境导出还是挺快的，因为有4台tikv，导出的时候在各台上生成备份目录，然后收集在一起就能恢复了。期间在测试环境进行几次测试，在测试环境恢复都正常，因为测试环境的数据量小，我甚至在1个tidb1个pd1个tikv的环境下也能还原成功。那就用它了，我想。
然而我还是想简单了，正式环境导出的数据一个库是150g，一个库是250g，好像导出数据会小很多，应该是有压缩了吧。好了，把备份拷到移动硬盘，准备拿到新的备份服务器上恢复，顺便说一下，对于我们这种穷人，新的备份服务器实际上配置是不高的，3台虚机，配置为：1台18核32g，1.2t机械盘，2台16核32g，1.2t机械盘，如果有看到这个配置认为我是瞎折腾，那就不要看下去了。实际上最后我是折腾成功了。
然后我把备份拷到其中一台，然后把目录共享成nfs给其它两台，一切就绪，然后：
nohup tiup br restore db
–pd “${PDIP}:2379”
–db “xxxxxx”
–storage “local:///data/tidb/db_bak/xxxxx”
–log-file /data/tidb/db_bak/xxxxfull.log > br_bak.log &
然后满心欢喜的等着，然后就出现本帖标题的问题了，试了几次，一样的问题，吐血了，这样麻烦了，好不容易拷下来的备份，恢复不了，这不扯蛋吗？然后来这边问，看来都是款爷都说我机器不行，pd搞挂了等等，没给出个什么建议来，唉，看来还是得靠自己啊。
拼命地看官方文档，看pd配置项，看tikv优化项，看grpc配置相关，想破脑袋，做了n多次的测试，最终还是还原成功了了。
以下是方法与思路：
1、既然是pd由于grpc问题leader飘走导致br进行不下去，那就不要使用多台pd，只让一台pd运行即可，避免它因为网络或者cpu相关资源leader飘走，然后为了减少pd资源，先把max-replicas改为1，只1个副本。
2、优化tikv的配置，主要是server. grpc-concurrency相关的，然后把性能测试中要求的写和读buffer也配置好内存大小。 backup. num-threads: 2，反正就减少对cpu的占用。留些资源给br。
3、br的参数相关，减少concurrency，然后不进行checksum
nohup tiup br restore db
–pd “10.1.40.22:2379”
–db “xxxxx”
–concurrency 2
–checksum=false
–storage “local:///tidb/db_bak/xxxx”
–log-file /tidb/db_bak/xxxxxfull.log > br_xxxxbak.log &
这些优化做完之后，br在执行的时候相当稳定，虽然因为库比较大，每个库恢复时间为4-5个小时，但总算中间不出错，导入成功了，查询了一下表记录，基本上都正常了，进度条只能做为参考，到100%的时候还会运行很久，大家不要着急。
然后为了追上mysql的进度，把bin-log都下载到本地，使用dm工具慢慢追赶中。
顺便说一下我用的tidb都是做为mysql-5.7的历史备份库，使用dm做数据同步的，如果这一部分有同学想讨论可以私聊。
对了，导入成功之后，记得把副本数改为3，然后增加pd节点，以防pd故障导致的数据丢失。
1 个赞