关于git同步的一个棘手问题-尚未解决
这是我昨天也就是10月15日测试的一个东西，源于周六的停电，为了万无一失，只能提早进行测试和恢复。
停电意味着公司内网后台——》gitab仓库这个定时上传的线路没了（mysql+tomcat），只能用线上服务器临时部署的后台给他们发布文章。
我大致记录下需要做什么。事先说明，这条路径是单向传输的！
1、公司内网停掉定时任务同步脚本，线上服务器也要停掉从gitlab拉取代码的定时脚本（当然不停也没问题，除非你知道什么时候来电，趁定时任务脚本跑起来之前恢复，这个手速要求非常高，不建议。后面我会说明为什么要停，恢复会有一个git代码更新冲突）
2、开启线上数据库，内网数据同步到线上去；开启线上发布后台，确认配置文件连的数据库为线上数据库地址；
3、考虑到后台放线上的不安全性（据说以前被黑客入侵过，当时跟经理商量过用ip+端口方式给运营的人进行访问，叫他们先提供出口ip，方便针对端口控制白名单访问，当然域名也可以做iptables规则啦，但同样的功能肯定是考虑最简单的方法嘛~~），开白名单访问
然后就可以叫运营的人发测试文章进行测试了，非常成功。
问题是来电之后的恢复！
需要把上面的传输线路逆过来运行一遍。
1、先给线上只能拉取代码的账号开有上传的权限（gitlab控制台从reporter改成maintainer角色），手动上传同步回gitlab去
2、线上数据库数据同步回内网（运营的人发完文章不仅在服务器上新增文件，数据库数据也有新增的）
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这条线路在我测试前，被我关了，内网ip+端口能看到他们发的文章，需要同步到线上。而我已经把 线上测试的文章已经推到 gitlab上了，又怕他们会催着问内网发的文章一直没有更新到线上，中心催，我只能把还在跑的同步git进程干掉了，当时一个心痛呀，说不定再过多几分钟，就被我测出来，实际恢复时间需要多久。
话说这个仓库已经算比较小的了，大的何止40多万个objects~~~~
停掉这个进程之后也是有点问题要处理，我都知道肯定有问题，所以先删掉线上后台发布的测试文章，然后同步回gitlab，线上数据库也同步回内网数据库去，然而，内网新发的正式文章 add 到gitlab还是说我代码落后gitab仓库的数据。最后只能git push --force 强制推上去 = =
我都担心这样粗暴恢复会不会有什么潜在问题。。。。
问题来了，有没有什么办法能把恢复供电之后，线上发了文章后，比较快而准地恢复到内网呢？？！！因为以前从来没试过从gitlab同步回数据到内网的。
（幸好周六说不用发文章，而且貌似也没停电，不然今天根本无法出去浪，囧囧。。。）
