从 SQL 治理到智能运维：金仓全栈兼容与高可用落地指南

企业数据库国产化已经从“能否迁移”进入“能否稳定运行”的阶段。哈尔滨金仓技术沙龙围绕全栈适配兼容与高可用实践，集中讨论了四类直接影响项目成败的问题：金融级 SQL 治理、业务系统迁移适配、Agent 驱动运维，以及高可用体系建设。

这些主题并非彼此孤立。迁移时遗漏的 SQL 差异会变成生产故障，缺少基线的高可用架构难以验证，而没有边界控制的智能运维又可能放大操作风险。更稳妥的做法，是把兼容性扫描、迁移验证、运行监控和故障处置串成一条可审计的工程链路。

SQL 兼容不是“语法能执行”

数据库兼容性至少包含四个层面：

• 语法兼容：分页、序列、日期函数、字符串函数和存储过程能否正确解析。
• 语义兼容：空字符串、NULL、隐式类型转换和排序规则是否产生相同结果。
• 驱动兼容：JDBC 驱动、连接池、参数绑定和批量写入是否符合应用预期。
• 性能兼容：SQL 即使返回相同结果，也可能因为执行计划、索引选择或统计信息变化而变慢。

金融级 SQL 治理尤其不能只统计“执行成功率”。迁移团队还应记录 SQL 指纹、调用频率、P95 延迟、扫描行数、返回行数和异常类型。一个每天执行一次的慢查询，与每秒执行数百次、单次只慢 20 毫秒的查询，对系统的影响完全不同。

建议在改造前建立三份清单：高频 SQL、关键交易 SQL、数据库特性依赖。迁移后逐项回放并比对结果集与性能指标，避免上线前只跑功能测试。

迁移适配最容易漏掉的边界

业务系统迁移常见问题通常藏在主流程之外，例如定时任务、报表、历史脚本和第三方组件。应重点检查以下内容：

迁移策略也不应只是“一次导完再切换”。对停机窗口敏感的系统，可以拆成全量迁移、增量同步、业务校验、灰度切流和回退观察五个阶段。每个阶段都要定义通过条件，而不是依靠现场判断。

可以这样实践：先生成数据库对象清单

下面给出一个可改造的迁移前检查示例。它基于标准 information_schema，用于导出表、列和约束清单。由于不同金仓产品版本、兼容模式和客户端工具可能存在差异，运行前请将连接命令和系统目录查询替换为现场版本支持的形式。

先设置连接参数：

export DB_HOST="127.0.0.1"
export DB_PORT="54321"
export DB_NAME="appdb"
export DB_USER="audit_user"
export PGPASSWORD="change-me"

创建 inventory.sql：

\pset format csv
\pset footer off

SELECT
    table_schema,
    table_name,
    column_name,
    ordinal_position,
    data_type,
    character_maximum_length,
    numeric_precision,
    numeric_scale,
    is_nullable,
    column_default
FROM information_schema.columns
WHERE table_schema NOT IN ('information_schema', 'pg_catalog')
ORDER BY table_schema, table_name, ordinal_position;

如果现场提供兼容 psql 参数的客户端，可以这样导出；否则将命令名替换为实际客户端：

psql \
  -h "$DB_HOST" \
  -p "$DB_PORT" \
  -U "$DB_USER" \
  -d "$DB_NAME" \
  -f inventory.sql \
  > columns.csv

wc -l columns.csv
sha256sum columns.csv > columns.csv.sha256

在源库和目标库分别执行后，可以先进行结构级比较：

sort source-columns.csv > source-columns.sorted.csv
sort target-columns.csv > target-columns.sorted.csv

diff -u source-columns.sorted.csv target-columns.sorted.csv > schema.diff || true
less schema.diff

这个脚本不能替代官方迁移评估工具，但适合作为可审计的补充材料。进一步可以增加索引、视图、触发器、序列、函数和权限信息，并将差异文件纳入迁移验收记录。

Agent 可以参与运维，但不能直接接管生产权限

Agent 驱动运维的价值，不只是把告警内容改写成自然语言，而是自动完成证据收集与处置编排。例如收到数据库延迟告警后，Agent 可以依次查询监控指标、定位时间窗口、关联变更记录、生成诊断摘要，再推荐经过审批的操作手册。

一个适合早期落地的工作流是：

name: database-latency-triage
trigger:
  alert: db_p95_latency_high

steps:
  - id: collect_metrics
    action: monitoring.query
    inputs:
      range: 15m
      metrics:
        - query_latency_p95
        - active_connections
        - lock_wait_count

  - id: collect_changes
    action: change_system.list
    inputs:
      range: 2h

  - id: summarize
    action: llm.generate
    inputs:
      prompt: |
        根据监控数据与变更记录生成诊断摘要。
        只引用输入中存在的证据；证据不足时明确写出未知项。
        不生成删除数据、终止实例或切换主库的命令。

  - id: request_approval
    action: ticket.create
    inputs:
      severity: high
      require_human_approval: true

这是一份与具体平台无关的假设性配置，需要映射到企业现有的监控、工单和模型网关。生产环境中应坚持只读优先、最小权限、命令白名单、人工审批和完整审计。主备切换、批量终止会话、修改参数等高风险操作，不应仅凭模型输出自动执行。

高可用不是部署完成，而是验证完成

高可用体系的目标不是“有一台备库”，而是在明确的故障范围内满足恢复时间目标（RTO）和恢复点目标（RPO）。项目需要验证的不只是数据库进程故障，还包括网络分区、磁盘写满、复制延迟、连接池缓存旧地址，以及应用事务在切换期间的行为。

上线前至少应完成以下检查：

• 明确同步或异步复制策略，以及各自对延迟和数据保护的影响。
• 对连接超时、查询超时和事务重试设置上限，避免无限重试放大故障。
• 执行真实的主备切换演练，并记录探测、选主、路由恢复和业务恢复耗时。
• 验证切换期间是否出现重复写入、未知提交状态或序列冲突。
• 确认备份能够恢复，而不只是确认备份任务显示成功。
• 为回切过程准备独立步骤，避免故障恢复后长期运行在临时拓扑上。

从小范围验证开始

金仓全栈兼容落地可以从一个边界清晰、调用链完整的业务模块开始。先盘点 SQL 与数据库对象，再建立结果和性能基线；随后完成迁移演练、故障注入与回退验证；最后才逐步引入 Agent 辅助诊断。

需要警惕两个极端：只关注兼容率而忽略长周期运行风险，以及为了追求自动化而跳过审批和审计。国产化数据库建设真正要交付的不是一次成功切换，而是一套可以重复迁移、持续治理、定期演练并能够解释故障的运行体系。