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

何傲 2022-07-23 09:14:00
作者介绍

何傲,神州数码集团高级开发工程师,长期从事于技术研发、数据库运维和系统架构方面的工作,分布式技术爱好者,TiDB社区技术布道师。目前专注在分布式数据库领域的研究和应用,负责神州数码TiDB团队项目交付、技术咨询、生态研发以及团队管理等相关工作。

 

一、测试背景

 

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 informationVersion:        12.1.0-eeRevision:       1f2e6f3f6d8Directory:      /home/git/gitlabDB Adapter:     PostgreSQL

 

三、测试场景

 

 

四、测试过程

 

简单起见,我们直接使用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.1psql:/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.1psql:/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.ymlsudo /etc/init.d/gitlab restartsource=rack-timeout id=oMeadFm1kN1 timeout=60000ms state=readyStarted GET "/users/sign_in" for 10.3.74.126 at 2022-05-31 16:19:18 +0800Processing by SessionsController#new as HTMLCompleted 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、场景对比

 

1)Project List

 

  • CockroachDB

 

访问页面正常,日志无报错信息。参考登录成功后的跳转效果。

 

  • YugabyteDB

 

访问页面正常,日志无报错信息。参考登录成功后的跳转效果。

 

  • 对比结果两者都支持。

 

2)Project View

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

3)Repository View

 

  • CockroachDB

 

 

 

  • YugabyteDB

 

 

 

  • 对比结果两者都支持。

 

4)Branch List

 

  • CockroachDB

 

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

5)Issue List

 

  • CockroachDB

     

 

  • YugabyteDB

     

 

 

  • 对比结果两者都支持。

 

6)Issue View

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

7)Merge Request List

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

8)Merge Request View

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

9)Project Members

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

10)New Project

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果

     

CockroachDB:进入到创建项目页面返回500异常,日志报错信息。“ActionView::Template::Error (PG::UndefinedColumn: ERROR: column “namespaces.rowid” does not exist”。
 
YugabyteDB:提交导入请求后持续加载中,观察日志无报错,一段时间后跳转到创建好的项目页面。

 

11)GitLab Import

 

  • CockroachDB

 

  • YugabyteDB

 

 

  • 对比结果

 

CockroachDB:不能进去到新建项目页面,无法导入项目。
 
YugabyteDB:提交导入请求后持续加载中,观察日志无报错。怀疑是gitlab权限问题,改用root用户重启gitlab程序后导入成功。

 

12)New Commit

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

13)Create Branch

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

14)Create Issue

 

  • CockroachDB

 

 

  • YugabyteDB

     

 

  • 对比结果两者都支持。

 

15)Create Merge Request

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

16)PR Merge

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

 

 

  • 对比结果

 

CockroachDB和YugabyteDB出现相同的情况:提交Merge请求后持续加载中,一段时间后页面出现报错提示,无法再次提交merge,日志无异常。

 

17)Add Project Member

 

  • CockroachDB

 

 

  • YugabyteDB

 

 

  • 对比结果两者都支持。

 

五、测试结论

 

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

 

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

 

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

 

活动预告