Py学习  »  Git

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

DBAplus社群 • 1 年前 • 216 次点击  

作者介绍

何傲,神州数码集团高级开发工程师,长期从事于技术研发、数据库运维和系统架构方面的工作,分布式技术爱好者,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报错是否和数据库有关还需要进一步排查。


Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/137998
 
216 次点击