云海天狼1. 项目背景与挑战
企业级代码仓库的跨操作系统升级是个系统工程，去年我们团队就经历了从GitLab 15.8.1到16.10.10的版本跃迁，同时完成了底层操作系统从CentOS7到Rocky Linux 9.5的迁移。这个组合升级涉及到底层依赖库变更、数据库结构转换、服务配置迁移等多重挑战，整个过程就像给飞行中的飞机更换发动机——必须确保代码提交、CI/CD流水线等核心业务零中断。
关键难点：GitLab大版本升级通常要求逐版本递进（如15.8→15.11→16.0→16.10），而操作系统迁移又涉及glibc、PostgreSQL等基础组件的兼容性问题，两者叠加时处理不当极易导致数据损坏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境预检与兼容性评估
2.1 硬件资源核查
原CentOS7服务器配置为32核CPU/64GB内存/2TB NVMe存储，但Rocky9.5的GitLab 16.x对硬件有更高要求。通过官方容量计算器（https://docs.gitlab.com/ee/administration/reference_architectures/）重新评估后，我们将新服务器规格调整为：
- CPU：48核（满足2000并发用户）
- 内存：96GB（考虑Sidekiq内存泄漏历史问题）
- 存储：4TB NVMe + 10TB HDD（对象存储分离）
2.2 软件依赖检查
使用gitlab-rake gitlab:check命令发现关键冲突项：
code复制libicu60 → libicu72（影响多语言处理）
PostgreSQL 12 → 14（需提前升级）
Redis 6 → 7（配置语法变更）
通过编写兼容性矩阵表明确升级路径：
| 组件 | 当前版本 | 目标版本 | 迁移方案 |
|---|---|---|---|
| Ruby | 2.7.5 | 3.1.4 | 使用RVM隔离安装 |
| Git | 2.29.3 | 2.41.0 | 源码编译安装 |
| PostgreSQL | 12.12 | 14.9 | 先独立升级再迁移 |
3. 分阶段升级实施
3.1 数据备份策略
采用三级备份方案确保安全：
- 全量快照：LVM快照（耗时2分钟）
- 应用级备份：
gitlab-backup create（包含数据库和仓库） - 配置备份：/etc/gitlab目录tar打包
备份验证命令：
bash复制# 检查备份完整性
sudo grep "Backup complete" /var/log/gitlab/gitlab-rake/gitlab_backup.log
# 测试恢复（在临时环境）
sudo gitlab-backup restore BACKUP=1659135642_2022_07_29_15.8.1
3.2 操作系统迁移
采用双机并行模式降低风险：
- 新服务器安装Rocky9.5最小化系统
- 配置Pacemaker实现VIP漂移
- 通过rsync增量同步数据：
bash复制rsync -azP --delete \
--exclude='.cache/' \
--exclude='tmp/' \
git@old-server:/var/opt/gitlab/ /var/opt/gitlab/
3.3 GitLab递进升级
严格遵循官方升级路径：
mermaid复制graph LR
A[15.8.1] --> B[15.11.13]
B --> C[16.0.9]
C --> D[16.10.10]
关键操作记录：
bash复制# 每步升级前检查
sudo gitlab-rake gitlab:doctor:secrets
# 升级命令示例（以15.8→15.11为例）
sudo yum install gitlab-ee-15.11.13-ee.0.el7.x86_64
sudo gitlab-ctl reconfigure
sudo gitlab-rake db:migrate
4. 故障处理实录
4.1 PostgreSQL数据迁移异常
在15.11→16.0升级时出现索引损坏：
code复制ERROR: index "index_ci_builds_on_protected" contains unexpected zero page
解决方案：
- 进入维护模式：
bash复制sudo gitlab-ctl deploy-page up - 使用pg_repack重建索引：
sql复制CREATE EXTENSION pg_repack; SELECT pg_repack.repack('index_ci_builds_on_protected'); - 重新执行迁移：
bash复制sudo gitlab-rake db:migrate:status sudo gitlab-rake db:migrate
4.2 Sidekiq内存泄漏
升级后监控显示Sidekiq内存持续增长，24小时后达到80GB。通过调整并发参数解决：
ruby复制# /etc/gitlab/gitlab.rb
sidekiq['max_concurrency'] = 20
sidekiq['min_concurrency'] = 5
sidekiq['max_rss'] = 2_000_000 # 2GB
5. 性能调优实践
5.1 Puma线程优化
根据服务器CPU核心数调整：
ruby复制puma['worker_processes'] = 16 # 48核CPU的1/3
puma['min_threads'] = 5
puma['max_threads'] = 25
5.2 文件系统选择
测试不同文件系统性能后选择XFS：
| 文件系统 | 随机写IOPS | 仓库克隆耗时 |
|---|---|---|
| ext4 | 35k | 12.7s |
| XFS | 48k | 9.2s |
| Btrfs | 28k | 14.1s |
挂载参数优化：
bash复制# /etc/fstab
/dev/nvme0n1p1 /var/opt/gitlab xfs defaults,noatime,nodiratime,logbsize=256k 0 0
6. 验证与监控
6.1 功能回归测试
编写自动化测试脚本验证核心功能：
ruby复制# test_gitlab_upgrade.rb
describe 'GitLab Post-Upgrade' do
it 'API v4 should work' do
response = HTTParty.get('https://gitlab.example.com/api/v4/projects')
expect(response.code).to eq(200)
end
it 'Git operations should succeed' do
system('git clone https://gitlab.example.com/test/repo.git')
expect($?.success?).to be true
end
end
6.2 监控指标基准
升级前后关键指标对比：
| 指标 | 升级前（CentOS7） | 升级后（Rocky9.5） |
|---|---|---|
| API响应P99 | 420ms | 210ms |
| 仓库克隆带宽 | 1.2Gbps | 2.8Gbps |
| 并发流水线执行数 | 35 | 78 |
| 内存使用峰值 | 58GB | 42GB |
7. 经验总结
-
时间窗口选择：实际耗时比预估多3小时（总计9小时），主要消耗在PostgreSQL大表迁移（2.1TB的ci_builds表）。建议预留50%缓冲时间。
-
回滚方案验证：测试发现从16.x回退到15.x需要手动清理新增的数据库表，提前准备了清理脚本：
sql复制-- 回滚时执行 DROP TABLE IF EXISTS vulnerability_occurrence_pipelines; -
配置漂移问题：新旧系统配置差异导致Nginx报错，通过以下命令对比解决：
bash复制
diff <(gitlab-ctl show-config nginx) <(ssh new-server gitlab-ctl show-config nginx)
这次升级最终实现了零数据丢失、仅5分钟服务不可用窗口（计划内维护），CI/CD流水线性能提升达120%。对于类似规模迁移，建议至少安排：
- 1名GitLab专家全程主导
- 2名系统工程师负责OS层
- 1名DBA处理数据库迁移
- 测试团队同步验证