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

作者介绍

何傲，神州数码集团高级开发工程师，长期从事于技术研发、数据库运维和系统架构方面的工作，分布式技术爱好者，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)