GitLab在CockroachDB

和YugabyteDB上的兼容性

神州数码集团

何傲

1.

测试背景

GitLab是一款在全球范围内都非常流行的源代码管理工具，早期的版本当中用户可以选择使用MySQL或PostgreSQL两种数据库，但是从12.1.0版本开始官方就完全放弃了对MySQL的支持。

GitLab新版本中很多功能都基于PostgreSQL的特性开发，它是众多使用了PostgreSQL作为底层数据存储的标杆产品。

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

• 版本问题（开源版和商业版，高版本和低版本）

• 精细化权限控制

• 数据备份

• 基础设施利用率

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

CockroachDB和YugabyteDB是目前比较知名的实现了PG协议的新型开源分布式数据库，根据各自官网的描述：

CockroachDB supports the PostgreSQL wire protocol and the majority of PostgreSQL syntax. This means that existing applications built on PostgreSQL can often be migrated to CockroachDB without changing application code.

原文出处：https://www.cockroachlabs.com/docs/v21.1/postgresql-compatibility.html

YugabyteDB is a high-performance, cloud-native distributed SQL database that aims to support all PostgreSQL features.

原文出处：https://github.com/yugabyte/yugabyte-db

CockroachDB说支持绝大多数的PG语法，YugabyteDB说支持所有的PG特性，本系列测评文章用于对比这两款数据库对GitLab的支持程度如何，一定程度上能反映出对标准PostgreSQL的兼容情况。

2.

系统初始化

测试环境

用标准PostgreSQL部署的GitLab包含的数据库schema为：

CockroachDB启动流程

1、数据库初始化执行GitLab setup程序生成所需要的库表结构：

从上面的输出信息可以看到，GitLab初始化需要依赖PostgreSQL的Extension特性，但是很遗憾CockroachDB目前还不支持，在第一步就失败了，此时数据库中没有创建任何对象：

2、访问GitLab

从日志来看，是因为SQL执行的时候找不到目标表报错：

3、更新数据库版本

考虑到当前CockroachDB不是最新版本，有没有可能最新版已经支持extension功能，尝试升级一下版本到latest-v22.1：

再次执行setup创建数据库，发现还是报相同的问题“ActiveRecord::StatementInvalid: PG::FeatureNotSupported: ERROR: unimplemented: extension "pg_trgm" is not yet supported”，说明新版本也无法支持extension特性。

YugabyteDB启动流程

1、数据库初始化

修改GitLab配置文件把数据库连接切换到YugabyteDB，用相同办法初始化一个新库：

从以上输出信息可以看出，刚开始setup运行正常，可以正常创建extension和table，持续约20分钟后碰到创建索引失败，原因是YugabyteDB不能识别“gin”类型的索引，取而代之的类型是“ybgin”。

看一下到这一步数据库生成了哪些对象：

情况看起来比CockroachDB要好一些，但是比完整的库表结构还是差很多。

2、访问GitLab

此时依然无法访问GitLab主页面，从日志里面发现报错原因是缺少目标表：

3、更新数据库版本

同样地，我们尝试把YugabytesDB升级到最新版本，看是否已经完成了Gin索引兼容：

再次执行setup程序，这个过程比较顺利，大约30分钟以后程序正常退出无报错。这时候我们看一下数据库中的对象情况：

可以看到和标准PostgreSQL库对比完全一致。打开浏览器访问GitLab主页会自动跳转到登录页，查看日志无报错：

填写用户注册表单提交后新用户注册成功，自动跳转到GitLab主页面：

初步来看，GitLab功能没有受到切换数据库的影响，更详细的测试将在下一期中给大家呈现。

测试小结

1、CockroachDB v21.2不支持Extension功能，导致GitLab无法初始化数据库，最终启动失败，更新到最新版本v22.1后问题依旧存在。

2、YugabyteDB v2.9不支持Gin Index（Generalized inverted indexes），导致创建一部分表后报错，同样无法启动，但是更新到最新版本v2.13后问题解决，可以正常访问GitLab页面以及注册用户。

3、YugabyteDB支持PostgreSQL Extension，CockroachDB不支持。

下一步我们将尝试绕过GitLab生成数据库这一步骤，把一个带数据的标准GitLab库导入到CockroachDB和YugabyteDB中，选取一部分频繁使用的读写场景，再对比两者的兼容性表现。

3.

读写场景测试

测试环境

测试环境

测试过程

简单起见，我们直接使用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文件导入完成后数据库的情况：

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

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

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，再尝试打开页面登录已有用户，发现登录成功并跳转到首页。

3、场景对比

场景名称：Project View

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Repository View

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Branch List

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Issue List

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Issue View

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Merge Request List

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Merge Request View

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Project Members

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：New Project

CockroachDB

YugabyteDB

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

场景名称：GitLab Import

YugabyteDB

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

场景名称：New Commit

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Create Branch

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Create Issue

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：Create Merge Request

CockroachDB

YugabyteDB

对比结果：两者都支持

场景名称：PR Merge

CockroachDB

YugabyteDB

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

场景名称：Add Project Member

CockroachDB

YugabyteDB

对比结果：两者都支持

测试小结

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

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

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

下一步计划

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