GitLab在CockroachDB和YugabyteDB上的兼容性对比(二)-读写场景测试

测试背景

GitLab是一款在全球范围内都非常流行的源代码管理工具,早期的版本当中用户可以选择使用MySQL或PostgreSQL两种数据库,但是从12.1.0版本开始官方就完全放弃了对MySQL的支持。GitLab新版本中很多功能都基于PostgreSQL的特性开发,它是众多使用了PostgreSQL作为底层数据存储的标杆产品。

我们试想一下这种用户场景,某大型集团分为众多事业部,每个事业部甚至小团队可能都维护了自己的GitLab,从集团层面如何管理这些仓库就成了棘手的问题。比如:

  • 版本问题(开源版和商业版,高版本和低版本)
  • 精细化权限控制
  • 数据备份
  • 基础设施利用率

如果能有一套统一的GitLab环境,同时又具备良好的可扩展性和高可用性,那无疑是最好的解决方案。但是传统单机PostgreSQL数据库并不能满足以上需求,那能否考虑把GitLab跑在分布式数据库上?

CockroachDB和YugabyteDB是目前比较知名的实现了PG协议的新型开源分布式数据库,本系列测评文章用于对比这两款数据库对GitLab的支持程度如何,一定程度上能反映出对标准PostgreSQL的兼容情况。

在上一篇《系统初始化》中我们得出的结论是,CockroachDB无法通过GitLab的setup程序自动创建数据库schema导致无法启动,而YugabyteDB在初始化这个步骤一切正常可以正常启动GitLab。

本次测试我们先把一个标准的GitLab库以及铺底数据分别导入到这两个数据库中,看能否正常启动GitLab,再选一部分GitLab的核心业务场景来做对比测试,看看两者的兼容情况如何。

测试环境

  • CockroachDB
defaultdb=# select version();
                                      version
------------------------------------------------------------------------------------
 CockroachDB CCL v22.1.0 (x86_64-pc-linux-gnu, built 2022/05/23 16:27:47, go1.17.6)
(1 row)
  • YugabyteDB
gitlab=# select version();
                                                                                         version
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 PostgreSQL 11.2-YB-2.13.2.0-b0 on x86_64-pc-linux-gnu, compiled by clang version 12.0.1 (https://github.com/yugabyte/llvm-project.git bdb147e675d8c87cee72cc1f87c4b82855977d94), 64-bit
(1 row)
  • GitLab
GitLab information
Version:        12.1.0-ee
Revision:       1f2e6f3f6d8
Directory:      /home/git/gitlab
DB Adapter:     PostgreSQL

测试场景

Scene Type Scene name
read (9) - Project List
- Project View
- Repository View
- Branch List
- Issue List
- Issue View
- Merge Request List
- Merge Request View
- Project Members
write (8) - New Project
- GitLab Import
- New Commit
- Create Branch
- Create Issue
- Create Merge Request
- PR Merge
- Add Project Member

测试过程

简单起见,我们直接使用pg_dump来做数据迁移。

先从标准库中把schema和数据导出到sql文件中:

pg_dump --host 10.3.70.132 --port 32298 --user postgres --no-owner -W gitlabhq_production > /root/gitlabhq_production.sql

1、CockroachDB数据迁移

这里用psql客户端把备份出来的sql导入,如果执行过程中出现错误会自动跳过,并把错误信息打印出来:

psql --host 10.3.70.189 --port 26258 --user root gitlab -f /root/gitlabhq_production.sql > pg_import_crdb.log

从输出的错误信息中观察主要包含以下两类:

描述:  source SQL:
CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public
                                            ^
提示:  You have attempted to use a feature that is not yet implemented.
See: https://go.crdb.dev/issue-v/74777/v22.1
psql:/root/gitlabhq_production.sql:30: ERROR:  at or near "pg_trgm": syntax error: unimplemented: this syntax
描述:  source SQL:
COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams'

以上报错还是说extension不兼容的问题。

提示:  You have attempted to use a feature that is not yet implemented.
See: https://go.crdb.dev/issue-v/47420/v22.1
psql:/root/gitlabhq_production.sql:31396: ERROR:  at or near ".": syntax error: unimplemented: this syntax
描述:  source SQL:
CREATE INDEX index_issues_on_description_trigram ON public.issues USING gin (description public.gin_trgm_ops)

这个报错是由于CockroachDB还不支持operator class。不过这两个报错都是和索引相关,预计不会对DML操作有太大影响,暂时先忽略。

看一下sql文件导入完成后数据库的情况:

gitlab=# select C.relkind,count(C.relname) from pg_class C left join pg_namespace n on n.oid = C.relnamespace where n.nspname = 'public' group by C.relkind;
 relkind | count
---------+-------
 r       |   249
 i       |   890
 S       |   231
(3 rows)

除了差10个左右索引,其他都正常。这时候把GitLab数据库指向到这个新库,启动程序看能否打开页面:

sudo -u git -H editor config/database.yml
sudo /etc/init.d/gitlab restart
 
 
source=rack-timeout id=oMeadFm1kN1 timeout=60000ms state=ready
Started GET "/users/sign_in" for 10.3.74.126 at 2022-05-31 16:19:18 +0800
Processing by SessionsController#new as HTML
Completed 200 OK in 55ms (Views: 32.3ms | ActiveRecord: 9.7ms | Elasticsearch: 0.0ms)
source=rack-timeout id=oMeadFm1kN1 timeout=60000ms service=291ms state=completed

从日志来看正常跳转到登录页面无报错。再使用已有的用户看能否登录成功:

2、YugabyteDB数据库迁移

用前面同样的方法把sql文件导入到YugabyteDB中:

psql --host 10.3.70.189 --port 5434 --user postgres gitlab -f /root/gitlabhq_production.sql > pg_import_ygdb.log

大约执行了1个多小时,整个过程没报错,检查一下数据库对象:

gitlab=# select C.relkind,count(C.relname) from pg_class C left join pg_namespace n on n.oid = C.relnamespace where n.nspname = 'public' group by C.relkind;
 relkind | count
---------+-------
 S       |   231
 i       |   903
 r       |   249
(3 rows)

与标准库一致。

修改数据库连接重启GitLab,再尝试打开页面登录已有用户,发现登录成功并跳转到首页。

3、场景对比

场景名称 CockroachDB YugabyteDB 对比结果
Project List 访问页面正常,日志无报错信息。参考登录成功后的跳转效果。 访问页面正常,日志无报错信息。参考登录成功后的跳转效果。 两者都支持
Project View 两者都支持
Repository View 两者都支持
Branch List 两者都支持
Issue List 两者都支持
Issue View 两者都支持
Merge Request List 两者都支持
Merge Request View 两者都支持
Project Members 两者都支持
New Project CockroachDB:进入到创建项目页面返回500异常,日志报错信息。“ActionView::Template::Error (PG::UndefinedColumn: ERROR: column “namespaces.rowid” does not exist”。YugabyteDB:提交导入请求后持续加载中,观察日志无报错,一段时间后跳转到创建好的项目页面。
GitLab Import CockroachDB:不能进去到新建项目页面,无法导入项目。YugabyteDB:提交导入请求后持续加载中,观察日志无报错。怀疑是gitlab权限问题,改用root用户重启gitlab程序后导入成功。
New Commit 两者都支持
Create Branch 两者都支持
Create Issue 两者都支持
Create Merge Request 两者都支持
PR Merge CockroachDB和YugabyteDB出现相同的情况:提交Merge请求后持续加载中,一段时间后页面出现报错提示,无法再次提交merge,日志无异常。
Add Project Member 两者都支持

测试结论

1、CockroachDB在所有测试的场景中3个最终失败,分别是新建项目、导入已有GitLab项目、PR Merge。

2、YugabyteDB在所有测试场景中有1个最终失败,即PR Merge。

从本次测试结果来看,YugabyteDB对GitLab兼容性要好一些,关于PR Merge报错是否和数据库有关还需要进一步排查。

下一步计划

接下来会根据本次测试发现的问题进行分析定位,再尝试最小化改造Gitlab源码看能否兼容测试失败的场景。

1 个赞