【问题标题】:How to move Git repositories and minimize downtime如何移动 Git 存储库并最大限度地减少停机时间
【发布时间】:2010-08-30 14:25:55
【问题描述】:

我会将 Git 存储库从旧的 SCM 服务器移动到新的。我的主要关注点(当然,除了保真度)是尽量减少停机时间。这是我的计划:

  1. 在新机器上,使用git clone --mirror 克隆每个存储库
  2. 复制每个存储库的存储库挂钩
  3. 禁止访问旧服务器(我们使用 gitosis,因此删除除新服务器之外的所有用户的访问权限)
  4. 移动 DNS 条目,以便 Git 用户使用 DNS 别名
  5. 对新服务器上的每个存储库执行 git pull
  6. 对于新服务器上的每个存储库,编辑配置文件以删除 remote "origin" 部分。
  7. 开启对新服务器的访问权限

问题:

  1. 这看起来对吗?我特别关心第 6 步。
  2. 有什么方法可以减少停机时间吗?

谢谢。

【问题讨论】:

    标签: git downtime


    【解决方案1】:

    我会(如果旧服务器和新服务器之间无法通信):

    • 捆绑每个repo using git bundle
    • 在新服务器上复制捆绑包
    • 创建裸仓库
    • git fetch 来自每个空的裸仓库中的那些捆绑包(没有要设置的来源)
    • 复制悬停钩子
    • 禁止访问旧服务器
    • 在每个 repo 上创建最后一个 git 包(增量包,非常快)
    • 复制那些小包
    • git fetch 小增量包的增量
      停机时间:没有要删除的来源>
    • 恢复访问权限

    如果新旧服务器之间可以通信(通过 SSL):

    • 我会创建一个特殊的“迁移”gitosis 用户,可以访问所有项目
    • clone --bare 新服务器上的每个项目
    • 复制悬停钩子
    • 禁止访问旧服务器
    • 在每个克隆的 repo 上创建最后一个 git fetch
    • 移除原点 停机时间>
    • 恢复访问权限

    【讨论】:

    • 感谢您的帮助,VonC。两个盒子之间有连接,所以我将使用克隆来移动 repo 内容。另外,感谢您对复制钩子的了解。我错过了。在这种情况下,我认为 clone --mirror 比 clone --bare 更好,因为镜像是裸露的,并且将源添加到配置文件中。有没有关于clone --mirror的东西我不知道哪个会导致你不推荐它?
    • @StretchyBill: git clone --mirror 对我来说看起来不错,已经在 stackoverflow.com/questions/1251713/backup-of-github-repostackoverflow.com/questions/1694608/… 等备份技术中使用过
    猜你喜欢
    • 1970-01-01
    • 2016-03-08
    • 2011-01-08
    • 2021-10-05
    • 2021-12-02
    • 2020-04-23
    • 2014-08-27
    • 1970-01-01
    相关资源
    最近更新 更多