关键在于将数据库类型、版本、部署形态、压测场景拆为正交维度,由 gitlab ci 的 matrix 自动组合执行;通过专用镜像封装工具链与标准化报告实现兼容性压测弹性与结果可比性。

用 parallel: matrix 做多维并发压测,关键不是“一键”,而是把数据库类型、版本、部署形态、压测场景这四类变量拆成正交维度,让 GitLab CI 自动组合执行。它不直接支持“异构数据库”抽象层,但能精准调度不同镜像、不同脚本、不同环境变量的作业实例——这才是兼容性压测真正需要的弹性。
明确压测维度并映射到 matrix 变量
不要试图在单个 job 里动态判断数据库类型。应提前定义清晰、互斥的维度标签,例如:
- DB_TYPE:mysql、postgresql、oracle、tidb、oceanbase、sqlserver(注意 Oracle/SQL Server 需用 Windows Runner 或容器化客户端)
- DB_VERSION:8.0、12、23c、v6.5、4.3.2(各数据库语义版本需与实际镜像 tag 对齐)
- DEPLOY_MODE:standalone、cluster、docker-compose、k8s-statefulset(影响连接地址、高可用校验逻辑)
- WORKLOAD:tpcc、sysbench-oltp-read-write、ycsb-load、jdbc-stress(每个 workload 对应独立脚本和参数文件)
这些变量不是全量组合,而是按需交叉。比如 OceanBase 只跑 DEPLOY_MODE: docker-compose 和 WORKLOAD: jdbc-stress,避免无效作业。
为每类数据库准备专用执行镜像
matrix 本身不解决兼容性问题,它只负责分发。真正的兼容性保障来自预构建的、带完整客户端工具链的镜像:
GitHub Hosts 更新工具(仅限中国用户),安全更新系统hosts文件,保留原有非GitHub条目,仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。
-
ghcr.io/your-org/db-tester:mysql-8.0:含 mysql-client、sysbench、自研 jdbc-driver-tester.jar -
ghcr.io/your-org/db-tester:pg-12:含 pgbench、psql、pg_isready、JDBC 连接池健康检查脚本 -
ghcr.io/your-org/db-tester:ob-4.3.2:含 obclient、oat-cli、obproxy、适配 OBProxy 的 JDBC URL 模板
镜像内封装连接初始化、权限校验、schema 准备、结果归一化(如将不同数据库的 latency 单位统一转为 ms),确保每个作业输出结构一致,便于后续聚合分析。
用 needs + rules 精准控制执行依赖与跳过逻辑
数十个并发作业不能无序乱跑。利用 needs 显式声明前置条件,用 rules 动态裁剪无效组合:
- 所有
WORKLOAD: tpcc作业必须needs: - setup-tpcc-schema,该 job 独立运行一次,生成通用 schema SQL 并作为产物上传 - 对
DB_TYPE: oracle,添加rules: - if: $CI_RUNNER_TAGS =~ /windows/,自动将作业路由到 Windows Runner,避免 Linux 容器中执行失败 - 当
DB_VERSION为 EOL 版本(如 mysql:5.7),用rules: - if: $DB_VERSION == "5.7" && $CI_PIPELINE_SOURCE != "schedule"仅在定时流水线中运行,MR 流水线跳过
结果归集与失败根因定位要前置设计
并发压测最怕“一堆红点看不出哪错”。建议在每个 job 结尾强制执行:
- 生成标准化 JSON 报告(含 DB_TYPE、VERSION、QPS、P95-latency、error-rate、connection-leak-count)
- 用
artifacts: paths:上传报告,并设置expire_in: 1 week - 触发一个汇总 job,拉取全部 JSON,用 jq 或 Python 脚本生成 Markdown 兼容性矩阵表,自动标红超时或错误率 > 5% 的单元格
- 对失败 job,自动提取日志中匹配
ERROR|ORA-|FATAL|timeout的前 20 行,写入 summary 字段,方便在 GitLab UI 一眼定位
这样,数十个并发作业跑完,你看到的不是一个滚动日志瀑布,而是一张可读、可筛选、可存档的兼容性看板。










