在跨机房、跨云的数据校验场景中，校验工具与数据库之间的数据传输往往暴露在不可信的网络环境中。

gt-checksum v4.0.0 新增 SSL 加密连接支持，源端和目标端可独立配置，让校验和修复过程中的数据传输不再"裸奔"。

---

一、功能简介

v4.0.0 为 gt-checksum 和 repairDB 同时新增了 SSL/TLS 加密连接支持。通过 8 个新增配置参数，源端和目标端可以独立配置各自的 SSL 证书和加密模式。

参数说明

gt-checksum 参数（源端 + 目标端）：

参数名	可选值	默认值	说明
srcSslCa	文件路径	空	源端 CA 证书文件路径
srcSslCert	文件路径	空	源端客户端证书文件路径
srcSslKey	文件路径	空	源端客户端密钥文件路径
srcSslMode	见下表	PREFERRED	源端 SSL 模式
dstSslCa	文件路径	空	目标端 CA 证书文件路径
dstSslCert	文件路径	空	目标端客户端证书文件路径
dstSslKey	文件路径	空	目标端客户端密钥文件路径
dstSslMode	见下表	PREFERRED	目标端 SSL 模式

repairDB 参数（仅目标端）：

参数名	说明
dstSslCa	目标端 CA 证书文件路径
dstSslCert	目标端客户端证书文件路径
dstSslKey	目标端客户端密钥文件路径
dstSslMode	目标端 SSL 模式

为什么 repairDB 只有目标端参数？ repairDB 是修复工具，只连接目标端数据库执行修复 SQL，不需要源端连接，因此只需配置目标端 SSL 参数。

SSL 模式说明

模式	说明	需要 CA 证书？
DISABLED	禁用 SSL，不加密连接	否
PREFERRED	优先使用 SSL，服务端不支持时回退到非加密连接	否
REQUIRED	必须使用 SSL 加密，但不验证服务端证书	否
VERIFY_CA	验证服务端 CA 证书链	是
VERIFY_IDENTITY	验证 CA 证书链和服务端身份（主机名）	是

使用方式非常简单，在配置文件 gc.conf 中添加几行即可：

; 最小配置：仅要求加密，不验证证书
srcSslMode=REQUIRED
dstSslMode=REQUIRED

---

二、功能作用及使用场景深入解读

2.1 为什么需要 SSL 加密连接？

在数据校验和修复场景中，gt-checksum 需要从源端和目标端大量读取数据进行比对。如果连接未加密，数据在传输过程中存在被窃听或篡改的风险。

场景一：跨机房/跨云校验

源端和目标端分别部署在不同云平台，校验流量经过公网传输。如果没有 SSL 加密，数据包可以被中间节点抓取和分析。

场景二：安全合规要求

金融、医疗、政务等行业对数据传输有严格的加密要求。数据库审计系统可能要求所有数据库连接必须使用加密通道，即使是只读查询也不例外。

场景三：共享网络环境

在 Kubernetes 集群或共享 VPC 中，不同租户的流量可能共享物理网络。虽然有网络隔离，但深度防御（Defense in Depth）原则要求在传输层也做加密保护。

场景四：修复 SQL 中的敏感数据

repairDB 执行的修复 SQL 可能包含用户个人信息、交易记录等敏感数据。这些 SQL 文本通过明文连接传输时，等同于将敏感数据直接暴露在网络上。

2.2 五种 SSL 模式：从"只加密"到"全面验证"

gt-checksum 提供了五种 SSL 模式，覆盖从最低安全要求到最高安全级别的全部场景：

DISABLED——明确禁用

srcSslMode=DISABLED

显式禁用 SSL。适用于已经在网络层面做了加密（如 VPN、专线），或者在完全可信的内网环境中使用。

PREFERRED——自适应模式（默认值）

srcSslMode=PREFERRED

优先尝试 SSL 连接，如果服务端不支持则回退到非加密连接。这是设置了其他 SSL 参数但未显式指定 mode 时的默认值。适用于过渡期场景——源端和目标端可能部分启用了 SSL。

REQUIRED——强制加密

srcSslMode=REQUIRED

强制使用 SSL 加密，但不验证服务端证书。这意味着传输数据是加密的，但客户端不会检查服务端证书是否由可信 CA 签发。适用于内部环境，需要加密但不担心中间人攻击的场景。

VERIFY_CA——验证证书链

srcSslCa=/path/to/ca.pem
srcSslMode=VERIFY_CA

验证服务端证书是否由指定的 CA 签发。需要提供 CA 证书文件（srcSslCa 或 dstSslCa）。这是生产环境推荐的最低安全级别。

VERIFY_IDENTITY——全面验证

srcSslCa=/path/to/ca.pem
srcSslMode=VERIFY_IDENTITY

在验证 CA 证书链的基础上，还验证服务端身份（主机名匹配）。这是最高安全级别，能有效防御中间人攻击。使用此模式时，服务端证书的 CN 或 SAN 必须与 DSN 中的主机名一致。

2.3 客户端证书认证

除了验证服务端身份，gt-checksum 还支持双向 TLS 认证（mTLS）——客户端也向服务端出示证书。适用于数据库配置了 REQUIRE X509 或 REQUIRE SUBJECT 的场景。

; 源端 mTLS 配置
srcSslCa=/path/to/ca.pem
srcSslCert=/path/to/client-cert.pem
srcSslKey=/path/to/client-key.pem
srcSslMode=VERIFY_CA

同时验证所有证书文件必须存在且可读，否则启动时报错退出，避免运行时才发现证书缺失。

2.4 源端和目标端独立配置

gt-checksum 的一个关键设计是源端和目标端完全独立配置 SSL 参数。这意味着：

• 源端使用 VERIFY_CA，目标端可以使用 REQUIRED
• 源端和目标端可以使用不同的 CA 证书
• 源端启用 SSL，目标端可以不启用

; 源端：严格的证书验证
srcSslCa=/certs/source-ca.pem
srcSslCert=/certs/source-client.pem
srcSslKey=/certs/source-client-key.pem
srcSslMode=VERIFY_CA

; 目标端：仅加密
dstSslMode=REQUIRED

这种设计源于真实生产环境的需求——源端可能是外部公司提供的数据库（使用他们的 CA），目标端是内部数据库（使用内部 CA 或暂未配置证书）。

2.5 SSL 参数激活条件

SSL 配置并非无条件生效。gt-checksum 设计了明确的激活条件：

1. 至少一个 SSL 参数非空：srcSslCa、srcSslCert、srcSslKey、srcSslMode 中至少有一个不为空，才激活源端 SSL 配置。目标端同理。
2. 驱动必须为 MySQL：Oracle 数据源不支持此配置。代码中通过 SrcDrive == "mysql" 和 DestDrive == "mysql" 进行判断。
3. mode 未设置时默认 PREFERRED：如果设置了其他 SSL 参数（如 srcSslCa）但未设置 srcSslMode，默认使用 PREFERRED 模式。
4. 向后完全兼容：未配置任何 SSL 参数时，行为与 v3.x 完全一致，DSN 不会被修改。

---

三、功能使用演示

3.1 最小配置：仅要求加密

不关心证书验证，只希望数据传输加密：

srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1

; 两端都要求 SSL 加密，不验证证书
srcSslMode=REQUIRED
dstSslMode=REQUIRED

启动后，gt-checksum 会在日志中输出 TLS 配置已应用（DSN 中的密码会被脱敏）：

$ gt-checksum -c gc.conf

Initializing gt-checksum
Reading configuration files
Source SSL: mode=REQUIRED (encryption only, no certificate verification)
Destination SSL: mode=REQUIRED (encryption only, no certificate verification)
...

3.2 完整配置：CA 证书验证

生产环境推荐使用 VERIFY_CA 模式，验证服务端证书：

srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1

; 源端 SSL：完整证书验证
srcSslCa=/etc/ssl/certs/source-ca.pem
srcSslCert=/etc/ssl/certs/source-client.pem
srcSslKey=/etc/ssl/private/source-client-key.pem
srcSslMode=VERIFY_CA

; 目标端 SSL：完整证书验证
dstSslCa=/etc/ssl/certs/dest-ca.pem
dstSslCert=/etc/ssl/certs/dest-client.pem
dstSslKey=/etc/ssl/private/dest-client-key.pem
dstSslMode=VERIFY_CA

3.3 混合配置：源端严格、目标端宽松

源端是外部数据库需要严格验证，目标端是内部数据库仅需加密：

srcDSN=user:ENC[...]@tcp(ext-mysql.example.com:3306)/db1
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1

; 源端：验证证书和主机名
srcSslCa=/etc/ssl/certs/external-ca.pem
srcSslMode=VERIFY_IDENTITY

; 目标端：仅加密
dstSslMode=REQUIRED

3.4 repairDB 配置

repairDB 使用相同的配置文件，只需配置 dstSsl* 系列参数：

dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1
fixFileDir=./fixsql

; 目标端 SSL
dstSslCa=/etc/ssl/certs/dest-ca.pem
dstSslCert=/etc/ssl/certs/dest-client.pem
dstSslKey=/etc/ssl/private/dest-client-key.pem
dstSslMode=VERIFY_CA

$ repairDB -c gc.conf

[REPAIR] Destination SSL: mode=VERIFY_CA (CA certificate verification enabled)
[REPAIR] Processing: fix-orders-001.sql ... OK
...

3.5 启动报错示例

证书文件不存在时，gt-checksum 会在启动阶段立即报错退出：

$ gt-checksum -c gc.conf

gt-checksum: Source SSL configuration error: CA certificate file not found: /path/to/nonexistent-ca.pem

客户端证书和密钥未配对时：

$ gt-checksum -c gc.conf

gt-checksum: Source SSL configuration error: both sslCert and sslKey must be provided together (got cert="/path/to/client.pem", key="")

---

四、最佳实践及使用约束

4.1 最佳实践

1. 生产环境建议使用 VERIFY_CA 或 VERIFY_IDENTITY

REQUIRED 模式虽然加密了传输数据，但不验证服务端证书，存在中间人攻击风险。生产环境建议至少使用 VERIFY_CA：

srcSslCa=/etc/ssl/certs/ca.pem
srcSslMode=VERIFY_CA
dstSslCa=/etc/ssl/certs/ca.pem
dstSslMode=VERIFY_CA

2. 配合 DSN 密文保护使用

SSL 加密了传输通道，但配置文件中的 DSN 密码仍然需要保护。建议配合 ENC[...] 密文和 gt-dsn-crypt 工具一起使用：

srcDSN=user:ENC[...]@tcp(10.0.0.1:3306)/db1
dstDSN=user:ENC[...]@tcp(10.0.0.2:3306)/db1
srcSslMode=VERIFY_CA
dstSslMode=VERIFY_CA

3. 内网环境可使用 REQUIRED 作为最低要求

如果校验任务完全在可信内网中运行，且服务端证书管理尚未完善，REQUIRED 模式可以作为过渡方案——至少保证传输数据不被明文窃取：

srcSslMode=REQUIRED
dstSslMode=REQUIRED

4. 证书文件权限管理

CA 证书和客户端密钥文件应设置适当的文件权限，避免未授权访问：

# 密钥文件仅 owner 可读
chmod 600 /etc/ssl/private/client-key.pem
# CA 证书和客户端证书可被工具进程读取
chmod 644 /etc/ssl/certs/ca.pem
chmod 644 /etc/ssl/certs/client.pem

6. 测试环境先验证再上线

首次配置 SSL 时，建议先在测试环境验证：

# 1. 确认证书文件可读
ls -la /path/to/ca.pem /path/to/client-cert.pem /path/to/client-key.pem

# 2. 使用 openssl 验证证书有效性
openssl x509 -in /path/to/ca.pem -text -noout
openssl verify -CAfile /path/to/ca.pem /path/to/client-cert.pem

# 3. 启动 gt-checksum 观察日志
gt-checksum -c gc.conf

4.2 使用约束

1. 仅对 MySQL-family 数据源生效

SSL 参数仅对 MySQL 数据源生效（包括 MySQL、GreatSQL、Percona Server、MariaDB）。Oracle 数据源不支持此配置，设置 SSL 参数会被静默忽略。这是由于 Oracle 使用完全不同的 SSL 机制（Oracle Net / TCPS），不在本次实现范围内。

2. VERIFY_CA / VERIFY_IDENTITY 必须提供 CA 证书

使用 VERIFY_CA 或 VERIFY_IDENTITY 模式时，必须提供对应端的 CA 证书文件（srcSslCa 或 dstSslCa），否则启动时报错。这是强制要求——没有 CA 证书就无法验证服务端证书链。

3. 客户端证书必须配对

使用客户端证书认证时，sslCert 和 sslKey 必须同时配置。只提供其中一个会在启动时报错。这是 TLS 协议的基本要求——证书和私钥必须匹配才能完成握手。

4. 所有证书文件必须存在且可读

gt-checksum 在配置解析阶段就会验证所有证书文件的存在性和可读性。文件不存在或无读取权限时，程序立即报错退出，不会进入校验流程。这是一个 fail-fast 设计，避免运行到一半才发现证书问题。

5. SslMode 不区分大小写

配置文件中的 srcSslMode 和 dstSslMode 值不区分大小写。verify_ca、VERIFY_CA、Verify_Ca 都是合法的。代码中会统一转为大写后进行匹配。

6. DSN 中已有的 tls= 参数会被替换

如果 DSN 连接串中已经手动指定了 tls= 参数，gt-checksum 会用 SSL 配置生成的值替换它，而非追加。这避免了 DSN 中出现两个 tls= 参数导致驱动行为不确定的问题。

---

五、总结

gt-checksum v4.0.0 的 SSL 加密连接支持，让数据校验和修复过程中的传输安全不再是空白。通过五种 SSL 模式覆盖从"仅加密"到"全面验证"的全部安全需求，源端和目标端独立配置的设计则适应了异构环境下的真实生产场景。

对生产环境的安全建议：

• 最低要求：REQUIRED 模式，保证传输加密
• 推荐配置：VERIFY_CA 模式，验证服务端证书链
• 最高安全：VERIFY_IDENTITY + 客户端证书，双向认证 + 主机名验证
• 完整方案：SSL 加密传输 + ENC[...] 密文保护密码 + 日志自动脱敏

一句话总结：srcSslMode=VERIFY_CA，让校验数据不再裸奔。

---

相关阅读

• gt-checksum v4.0.0 新功能解读系列文章（1）：断点续传——大任务中断不再从头跑
• gt-checksum v4.0.0 新功能解读系列文章（2）：自定义数据类型映射——适配复杂迁移场景
• gt-checksum v4.0.0 新功能解读系列文章（3）：反向回滚 SQL——修复可审计、可回退
• gt-checksum v4.0.0 发布：可续跑、可回滚、可审计的数据校验与修复能力全面升级
• gt-checksum 使用手册