在上一篇《系统初始化》中，我们得出的结论是 CockroachDB 无法启动，因为它无法通过 GitLab 的 setup 程序自动创建数据库模式，而 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复制
测试场景
| 场景类型 | 场景名称 |
|---|---|
| 阅读 (9) | - 项目列表 - 项目视图 - 存储库视图 - 分支列表 - 问题列表 - 问题视图 - 合并请求列表 - 合并请求视图 - 项目成员 |
| 写 (8) | - 新项目 - GitLab 导入 - 新提交 - 创建分支 - 创建问题 - 创建合并请求 - PR 合并 - 添加项目成员 |
测试过程
让我们直接使用 pg_dump 进行数据迁移以保持简单。
首先，将标准库中的模式和数据导出到 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复制
输出错误消息的观察结果包含以下两个主要类别。
Description: source SQL: CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public ^ Tip: 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 Description: source SQL: COMMENT ON EXTENSION pg_trgm IS 'text similarity measurement and index searching based on trigrams'复制
上面报错说明扩展与问题不兼容。
Description: 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 Tip: 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复制
大约执行了一个多小时，整个过程没有报错，检查数据库对象。
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)复制
与标准的 postgreSQL Schema 一致。
修改数据库连接重启GitLab，然后尝试打开页面登录已有用户，发现登录成功，跳转到首页。
3.场景对比
| 场景类型 | CockroachDB | YugabyteDB | 结果 |
|---|---|---|---|
| 项目清单 | 两者都支持 | ||
| 项目视图 | 两者都支持 | ||
| 存储库视图 | 两者都支持 | ||
| 分行列表 | 两者都支持 | ||
| 问题清单 | 两者都支持 | ||
| 问题视图 | 两者都支持 | ||
| 合并请求列表 | 两者都支持 | ||
| 合并请求视图 | 两者都支持 | ||
| 项目成员 | 两者都支持 | ||
| 新项目 | CockroachDB：转到创建项目页面并返回 500 个异常，记录错误消息“ActionView::Template::Error (PG::UndefinedColumn: ERROR: column "namespaces.rowid" does not exist" )提交导入请求，观察日志无误，一段时间后跳转到创建的项目页面。 | ||
| GitLab 导入 | CockroachDB：无法进入新建项目页面，无法导入项目。 YugabyteDB：提交导入请求后一直加载，日志没有报错。怀疑是gitlab权限问题，我用root用户重启了gitlab程序，导入成功。 | ||
| 新提交 | 两者都支持 | ||
| 创建分支 | 两者都支持 | ||
| 创建问题 | 两者都支持 | ||
| 创建合并请求 | 两者都支持 | ||
| 公关合并 | CockroachDB 和 YugabyteDB 也有同样的情况。 提交合并请求后，页面继续加载，一段时间后，页面显示错误信息，无法再次提交合并，日志也没有异常。 | ||
| 添加项目成员 | 两者都支持 |
测试结论
1. CockroachDB在所有测试场景中最终失败了三个，分别是New Project、Import Existing GitLab Project、PR Merge。
2. YugabyteDB在所有测试的场景中都有一个最终失败，即PR Merge。
从这次测试的结果来看，YugabyteDB 与 GitLab 的兼容性更好。需要进一步调查PR Merge错误是否与数据库有关。
下一步
下一步将分析定位本次测试发现的问题，然后尝试最小化修改Gitlab源码，看是否兼容测试失败场景。
原文标题：Compatibility of GitLab on CockroachDB and YugabyteDB (II) — Read and Write Scenario Testing
原文作者：he ao
原文地址：https://dzone.com/articles/compatibility-of-gitlab-on-cockroachdb-and-yugabyt-1
