关于git同步的一个棘手问题-尚未解决

关于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同步回数据到内网的。

  (幸好周六说不用发文章,而且貌似也没停电,不然今天根本无法出去浪,囧囧。。。)