后台同步逆向恢复
一、问题记录
这是我昨天也就是10月15日测试的一个东西，源于周六的停电，为了万无一失，只能提早进行测试和恢复。
停电意味着公司内网后台——》gitab仓库这个定时上传的线路没了（架构是：mysql+tomcat），只能用线上服务器临时部署的后台给运营同事发布文章。
我大致记录下需要做什么。事先说明，这条内网——》gitlab——》线上路径是单向传输的！
1、公司内网停掉定时任务同步脚本，线上服务器也要停掉从gitlab拉取代码的定时脚本（当然不停也没问题，除非你知道什么时候来电，趁定时任务脚本跑起来之前恢复，这个手速要求非常高，不建议。后面我会说明为什么要停，恢复会有一个git代码更新冲突）；
2、开启线上数据库，内网数据同步到线上去；开启线上发布后台，确认配置文件连的数据库为线上数据库地址；
3、考虑到后台放线上的不安全性（据说以前被病毒入侵过，当时跟经理商量过用ip+端口方式给运营的人进行访问，先提供他们家里的出口ip给我，然后我在云控制台安全组规则设置ip白名单，当然域名也可以做iptables规则，但同样的功能肯定是考虑最简单的方法嘛~~），这样就能限制只有他们的ip能访问线上临时后台，其他地址禁止访问。
最后就可以叫运营的人发测试文章进行测试了，这个线上发布的过程非常成功。
问题是来电之后的恢复！
需要把上面的传输线路逆过来运行一遍。
1、先给线上只能拉取代码的账号开有上传的权限（gitlab控制台从reporter改成maintainer角色），从单向传输变成能逆向传输，手动上传同步回gitlab去
2、线上数据库数据同步回内网（运营的人在线上发完文章不仅在服务器上会新增文件，数据库数据也有新增的，服务器新增文件，gitlab同步回内网即可；数据库有新增，则线上数据库同步回内网数据库）
3、公司内网后台运行拉取gitlab数据
第三个同步线上发的新闻过程很慢，拉取gitlab的核心命令是：
1 cd $git_home && 2 3 git fetch --all 4 git reset --hard origin/master
git fetch --all 运行count 完一堆文件后，需要先统计数量，有40多万个对象，然后就定着一动不动。看了十来分钟还是这个页面，又怕终端突然断了白跑，于是就放在后台运行。
然后时不时top看下跑完没有，我记得接近下午1点左右开始跑的，下午4点都没跑完。
想想比对40多万个对象的异同，有新增才更新，关键一刻没同步完，服务器负载就高居不下，load average的值都有2点多。
而且刚好我在做恢复测试这个过程中，公司的人竟然还发新闻，用的就是从内网——》gitlab ——》 线上这条线路，幸好内网——》gitlab这条线路在我测试前，被我关了，浏览器打开内网地址，能看到他们发的文章。只能同步到线上。而我已经把 线上测试的文章已经推到 gitlab上了，又怕他们会催着问内网发的文章一直没有更新到线上，我只能把还在跑的同步git进程干掉了，当时一个心痛呀，说不定再过多几分钟，就被我测出来，实际恢复时间需要多久。
话说这个仓库已经算比较小的了，大的何止40多万个objects~~~~
停掉这个进程之后也是有点问题要处理，我都知道肯定有问题，所以先删掉线上后台发布的测试文章，然后同步回gitlab，线上数据库也同步回内网数据库去，然而，内网新发的正式文章 add 到gitlab还是说我代码落后gitab仓库的数据。最后只能git push --force 强制推上去 = =
我都担心这样粗暴恢复会不会有什么潜在问题。。。。
问题来了，有没有什么办法能把恢复供电之后，线上发了文章后，比较快而准地恢复到内网呢？？！！因为以前从来没试过从gitlab同步回数据到内网的。
（幸好周六说不用发文章，而且貌似也没停电，不然今天根本无法出去浪，囧囧。。。）
二、问题解决
---解决时间：2021-10-19（周二）
周一上班的时候，想着这个问题总是要处理的，如果刚好停电那天是需要发文章的，始终都要恢复的，总不能叫人重新在内网后台在发布一次的。
就搜索一下“git pull/fetch 很慢怎么解决”， 终于让我找到解决方法：https://blog.csdn.net/u010595191/article/details/85054694
文章说对当前git仓库进行耗时分析，于是我复制一套一模一样的后台环境过去测试服务器，然后在git目录运行：
GIT_TRACE=2 GIT_CURL_VERBOSE=2 git fetch
运行完之后，返回信息没细看，再试试运行git fetch --all，挺快的~~
于是铤而走险，直接在正式版的内网发布后台的本地仓库执行节点清理命令
git gc --aggressive --prune=now
周一下午4点左右跑，外加周一整个晚上，周二上班终于跑完了。
然后重新执行同步，奇快无比~~~至此问题解决，感动 = =！
1 git fetch --all 2 git reset --hard origin/master
