10-06 16 views
一、背景
Gitlab现在已经发展到11+了,我们这边用的比较早,13年就开始了当时最新的版本是5.3,上线后便一直未升级,直到前几天服务器因年久失修宕机…
值得庆幸的是数据都还在,故事便从这里开始了……
二、新环境构筑
2.1 安装
安装过程省略,照官方文档就行https://github.com/gitlabhq/gitlabhq
根据自己要安装版本,先选择对应的分支,再找到gitlabhq/doc/install/installation.md
不过需要提示的是,在5.3时gitlab-shell是需要自己手动去clone安装,自6.9的版本开始集成成一条命令了
1 |
bundle exec rake gitlab:shell:install[v1.9.4] REDIS_URL=redis://localhost:6379 RAILS_ENV=production |
2.2 测试
安装好之后,打开浏览器测试,使用下面的信息登录:
1 2 |
root 5iveL!fe |
三、数据恢复
3.1 迁移
数据迁移分以下几步做:
1. 先将新搭建的gitlab的服务停掉,然后将其DB、gitlab-satellites、repositoriest备份(注意目录的权限)
2. 将旧平台的repositoriest目录复制到新的服务器上替换repositoriest目录
3. 在新平台的MySQL数据上新建一个schema,将旧平台的数据导入进去(不要直接往新平台的schema里面导,两个表结构不一样)
3.2 DB数据合并
通过navicat(db工具,我用的是navicat)查看gitlab的表结构,表很少,仔细分析会发现其实涉及到升级操作的主要就三张表:namespaces、projects、users、users_groups、users_projects
注:我讲的主要就三张表,如果有通过gitlab去管理issues、tags、keys等也照同样的方法恢复进去就行
恢复的顺序:
1. namespaces
2. projects (依赖namespaces)
3. users(这个也可以最先恢复)
4. users_groups(依赖users)
5. users_projects(依赖users、projects)
3.2.1 namespaces表
这张表中新增了“avatar”字段,但是允许为空,可直接恢复
3.2.2 projects表
这张表改动比较大如下图:
对于旧环境来讲,去掉了“default_branch”、“public”、“imported”这三个字段
新环境中增加了“import_url”、“visibility_level”、“archived”、“import_status”、“repository_size”
分析:
去掉的三个字段其实没什么好说的,把SQL语句导出来,批量去掉就行了
新增的几个字段分析DDL发现都是有默认值的,这就好办了
恢复
1. projects表导出sql
2. 用文本编辑器批量替换掉不要的三个字段
3. 将处理后的sql恢复到新环境中
3.2.3 users表
这张表我只说下关键的两个字段“confirmed_at”、“confirmation_sent_at”,这两个新增的字段的作用是,在新的版本中创建好一个用户后会向他的邮箱发一份确认邮件,在确认后这两个字段会存放发送和确认的时间,只有确认后的用户才允许登录(当然管理员可以在后台手动确认)。如果这两个字段是空,用户将无法登录。
恢复
1. 删除新环境中默认用户(root用户)
2. 将旧环境中的users表导出成sql
3. 恢复到新环境
4. 用update语句给新增的两个字段赋值(随便写个日期就好)
3.2.4 users_groups表和users_projects表
直接恢复
3.3 repositoriest数据恢复
1 2 3 4 5 6 7 8 |
su - git cd gitlab bundle exec rake gitlab:import:repos RAILS_ENV=production bundle exec rake gitlab:satellites:create RAILS_ENV=production bundle exec rake gitlab:check RAILS_ENV=production sudo service gitlab start |
整个迁移过程到此就结束了……
