CockroachDB 26.4：一年只需一次大版本升级，双机房 active-active 与后量子 TLS 同时落地
数据库运维团队最痛的不是”数据库跑挂了”，而是数据库没挂，但它每隔几个月就跟你要一次变更窗口。CockroachDB 26.4 —— 这个 2026 年 11 月 3 日发布的版本 —— 基本上就是在跟这种”例行打扰”算账。
官方博客开篇就把账摊开：一次大版本升级意味着一个变更申请、一次预演排练、一个维护窗口和一轮值班安排。而在此之前，为了跟上版本，这样的仪式一年要办两次。
一、从”一年两次”到”一年一次”
26.4 起，你可以从一个年份的 .4 版本直接跳到下一年的 .4 版本：26.4 → 27.4 → 28.4，中间的版本不必停留。
| 升级路径 | 26.4 之前 | 26.4 起 |
|---|---|---|
| 大版本节奏 | 每年两次 | 每年一次 |
| 跳级升级 | 不支持 | 26.4 → 27.4 → 28.4 直接跨 |
| 变更窗口 | 每版一次 | 每年一次 |
| skip-level upgrades 可用范围 | — | 自建、Standard、Advanced 均为 GA |
需要注意一个”看似反直觉”的细节：要升到 26.4，仍然要先经过 26.2。跳过中间版本的能力只对 .4 系列生效。.2 版本的 LTS 资格和支持窗口没有变化。
图：skip-level upgrades 让大版本升级收敛为每年一次（图片来源：Cockroach Labs 官方博客）
二、双机房 active-active：两个数据中心都能写
很多受监管行业跑的是两个数据中心，而不是三个。26.4 把”跨双机房 active-active”提升到和多区域集群同等的地位：
- – Active-active across two data centers（GA）：基于事务模式的逻辑数据复制，两个数据中心同时接受写入，多语句事务在两者之间原子复制。
- – 失败事务进死信队列：复制不会因为某个事务失败就整个暂停，而是把失败事务丢进 dead letter queue 后继续推进。
- – 边恢复边读（Preview）：在线恢复过程中已经开始对外提供读服务，应用回来得更早，恢复时间下降。
- – 从加密备份快速恢复：26.4 及之后版本生成的加密备份同样支持快速在线恢复；当备份支持时，直连下载恢复成为默认选项。
- – 可告警的 RPO：新指标报告每个备份计划距离最近一个可恢复点已经过了多久——这个数字可以直接接进告警系统。
三、给人和 Agent 都发身份：口令之外的那一套
官方的判断很直接：人会登出，Agent 不会。当 AI Agent 开始自己连生产数据库时，信任不能靠一个共享密码维系。
26.4 把身份、凭据与审计三件事一起做进了集群：
| 能力 | 状态 | 说明 |
|---|---|---|
| Passwordless sign-in | GA | OIDC 支持 PKCE，cockroach sql CLI 可通过 IdP 浏览器登录，凭据由 IdP 统一过期 |
| 工作负载身份映射到 SQL 用户 | GA | 开启 security.client_cert.san_required.enabled 后，客户端证书的 X.509 SAN 映射为 SQL 用户，可用 SPIFFE ID 等工作负载身份替代共享密钥 |
| 关闭 root 登录 | GA | 启动开关禁止 root 登录，杜绝用最高权限账号操作 |
| 表级审计日志 | GA | 记录谁动了哪张表、何时动，无论对方是人、服务还是 Agent |
加密方面，后量子 TLS 进入 GA，同时覆盖客户端到节点和节点到节点两类连接——这是对”先截获、后解密”式攻击的直接回应。此外，敏感集群设置、作为绑定参数传入的口令、以及嵌在备份/恢复/导入/changefeed URI 中的凭据，现在都会在 debug zip、日志、事件日志和语句包中被脱敏；依赖节点隐式云凭据的外部存储操作，改为必须显式授权。26.4 基于 Go 1.26.10 构建，不再信任近期出问题的 eMudhra 中间证书。
图：26.4 将后量子加密与身份体系一并纳入集群能力（图片来源：Cockroach Labs 官方博客）
图：敏感集群设置、绑定参数中的口令与 URI 内的凭据，默认从 debug zip、日志与语句包中脱敏（图片来源：Cockroach Labs 官方博客）
四、凌晨两点的问题：谁在阻塞谁
延迟突然抬升时，所有 DBA 都会问同一句话：哪个工作负载、哪条语句、谁在挡谁。26.4 让这批答案变成持久化、可查询、可长期留存的：
| 观测能力 | 变化 |
|---|---|
| 语句与事务执行洞察 | 集群级持久化，通过稳定的 information_schema 视图暴露，记录能活过节点重启，不再只存在于内存窗口 |
| 锁与 latch 竞争 | 新增 information_schema.crdb_contention_activity，同时给出等待中的语句和阻塞它的语句 |
| SQL CPU 时间 | 每次执行都测量，不再是抽样，SQL Activity 中不再出现”无样本”空档 |
| 会话历史 | Active Session History 默认携带 application name、user、plan、transaction，样本直接指向产生它的代码 |
| 指标下钻 | DB Console 指标可按区域或节点拆分到每一块大盘 |
| 内置视图 | crdb_tables、crdb_indexes、crdb_ranges、crdb_nodes、crdb_stores、crdb_databases，取代过去手工 join 内部表的做法 |
另外，Resource Manager 可以为工作负载保留最低 CPU 份额（minimum CPU guarantees），让批处理作业和支付服务共用集群时，关键流量不会被饿死；资源组可观测性处于 Private Preview。
图：information_schema.crdb_contention_activity 直接给出等待方与阻塞方（图片来源：Cockroach Labs 官方博客）
五、几处不显眼但很实用的日常优化
- – 节点间更省 CPU（Preview）：Cockroach Labs 自研的轻量 RPC 框架替代 gRPC 处理节点间流量，降低集群 CPU 占用。默认关闭；全量升级到 26.4 后逐节点加
--use-new-rpc打开。 - – 大表过期更便宜：行级 TTL 现在可以走过期列上的索引找过期行，而不是全表扫描，每次运行的开销与”过期行数”挂钩，而不是与”表有多大”挂钩。
- – IMPORT INTO 只在指定 locality 运行：对
REGIONAL BY TABLE表默认落在该表 home region，跨区域流量更少、异地节点失败更少。 - – Avro changefeed 可只读接入 Confluent 兼容 schema registry，适合不允许应用写 schema 的团队。
- – PostgreSQL 兼容性继续补齐：临时表支持
ON COMMIT DELETE ROWS/ON COMMIT DROP（Preview）；延迟绑定的 PL/pgSQL 存储过程可以先建表再在同一分支后续使用；语句级触发器配合 transition tables，让一次批量变更只审计一次而拿到全部受影响行；RETURNING现在支持OLD与NEW；另加json_object()、json_array()、any_value()、EXPLAIN EXECUTE、函数内查询计划出现在EXPLAIN ANALYZE中、DROP TYPE ... CASCADE、以及带二级索引时修改列类型。
图：CockroachDB 26.4 的五大主题：升级节奏、双机房 active-active、身份与加密、观测、运维成本（图片来源：Cockroach Labs 官方博客）
升级前必须知道的三件事
- 1. 默认收紧：如果你在用 SAN 客户端证书认证、依赖隐式云凭据的外部存储，或者使用 LEAKPROOF 函数，先读 release notes 的 breaking changes。
- 2. 统计信息会被清空：升级会清除已持久化的语句与事务统计，采集随后自动恢复。
- 3. 最后一步要”finalize”：语句级触发器、transition tables 和新的观测视图，需要在升级流程的最后一步 finalize 之后才会启用。
可用性方面：26.4 已在 CockroachDB Cloud 的部分集群上线，自建二进制版本约两周后发布。
小夏点评
一、”一年一次升级”是这版最有商业价值的一条，但它改变的是流程，不是技术。 skip-level upgrade 省下的是变更窗口、预演排练和一次值班，而不是”数据库变得更稳了”。真正要动的是你这边的变更管理制度：如果团队现在的节奏是”每个大版本都要走一次跨部门审批”，那一年一次根本不会自动发生——你需要在流程上把 .4 版本标成”年度计划内变更”，把中间的 .2/.3 版本变成”仅在必要时跟进”，否则跳级能力摆在那里，用的还是老习惯。反过来讲，这条能力对国内金融、政企这类审计严格的单位格外对口：把”数据库变更”从每半年一次的审计事件，变成一年一次并可预期的常规事件，审计成本也一起降下来了。
二、Agent 身份这一块，26.4 的真正分量在于”把审计提前做进架构”，而不是多了几个开关。 过去国内团队的做法通常是：给 Agent 发一个数据库账号，密码放在配置里，出事再翻日志。26.4 提供的组合是工作负载身份（SPIFFE ID 映射到 SQL 用户）+ 可过期凭据 + 表级审计日志 + 关闭 root 登录 + 默认脱敏——这五件合起来才构成”Agent 可以连生产库，但连完留痕、凭据随时能撤、密钥不会漏进日志”。单看任何一条都不稀奇，合起来才是一条完整链路。我的建议是分两步走：第一步先上后量子 TLS 和日志脱敏（这两条对存量应用零改动、纯收益），第二步再做工作负载身份映射（需要你的证书体系配合改造，别一次全推）。
三、给国内 IT 运维和开发者的启示：把 26.4 当成一次”运维负债盘点”的机会，而不是一次版本升级。 三条可落地的动作：一是利用持久化的 information_schema.crdb_contention_activity 做一次慢查询回溯——过去这类信息只在内存窗口里，重启就没了，现在能回看半年前的阻塞关系，正好用来定位那些”偶发但没人复现”的生产问题，并据此设置 Resource Manager 的最低 CPU 保证；二是按 locality 收敛 IMPORT INTO 和跨区域数据流，对跨省部署的集群，这一条直接关系到带宽成本和异地节点故障率，属于改配置就能拿到的确定性收益；三是升级前先跑一遍”隐式依赖扫描”：重点查隐式云凭据、LEAKPROOF 函数、以及依赖旧 Go 证书链的组件——26.4 基于 Go 1.26.10 并不再信任出问题的中间证书，这一类问题往往在升级当天才暴露，代价远高于提前查一遍。整体建议：自建环境按”先开关后默认”的顺序推进（先只开竞争视图和审计日志，观察一周数据再动 TLS 和身份），把一次大版本升级拆成几次可回退的小步，风险可控得多。
参考链接
- – 主源：Cockroach Labs《CockroachDB 26.4: One major upgrade a year with skip-level upgrades, run active-active across two data centers, and encrypt for the post-quantum era》（2026-11-03，作者 Tara Jana、Biplav Saraf）https://www.cockroachlabs.com/blog/cockroachdb-26-4/
- – 官方文档：What’s New in CockroachDB v26.4 https://www.cockroachlabs.com/docs/releases/v26.4
- – 官方文档：Upgrade to v26.4（升级路径与 breaking changes）https://www.cockroachlabs.com/docs/releases/upgrade-to-v26-4
- – 官方文档：CockroachDB Security（工作负载身份、审计日志与 TLS 配置）https://www.cockroachlabs.com/docs/stable/security
- – 官方文档：Manage CockroachDB Workloads（Resource Manager 最低 CPU 保证）https://www.cockroachlabs.com/docs/stable/manage/cockroach-workloads
