解读

面试官问“如何锁定版本”，并不是想知道“把软件包版本号写死”这么简单。
在国内 CouchDB 生产环境里，版本锁定通常涉及三条线：

1. 二进制包本身（yum/apt/容器镜像）
2. 集群内部各节点版本必须完全一致，否则复制与集群状态会异常
3. 应用侧依赖的 CouchDB 客户端库（如 nano、erica、pouchdb）也要与服务器版本对齐

回答时要体现“可重复、可回滚、可审计”的运维思路，并给出落地脚本或配置片段，才能打动面试官。

知识点

• CouchDB 版本号规则：三位语义化版本（Major.Minor.Patch），其中 Minor 升级可能引入新视图引擎行为，跨 Minor 升级需重建视图
• CentOS 7/8 常用锁定手段：yum-plugin-versionlock，写入 /etc/yum/pluginconf.d/versionlock.list
• Ubuntu 18/20 常用锁定手段：apt-mark hold couchdb
• 容器场景：使用 digest 级别锁定（couchdb@sha256:…）而非 tag，避免镜像重新打包后哈希变化
• 集群一致性：CouchDB 2.x/3.x 加入集群时会检查 / 返回的 version 字段，版本不一致直接拒绝 join
• 配置漂移检测：在 CI 里调用 curl -s http://node:5984/ 解析 JSON 的 version 字段，做每日巡检
• 回滚策略：提前在 yum/apt 仓库里保留 两个连续小版本，并本地打包 rpm/deb，确保紧急回滚不依赖外网

答案

线上环境我采用“三重锁定 + 自动校验”方案：

1. 操作系统层：CentOS 通过 yum versionlock add couchdb-3.3.2-1.el7.x86_64，把完整 release 号写进 /etc/yum/pluginconf.d/versionlock.list；Ubuntu 用 apt-mark hold couchdb
2. 容器化交付时，Dockerfile 里不写 couchdb:3.3.2，而是写 couchdb@sha256:7d8f9b…，并在镜像仓库关闭 overwrite 权限，保证任何时间 pull 都得到同一哈希
3. Ansible 编排里先执行 yum versionlock list | grep couchdb，若结果为空或版本号不符直接失败退出，防止人为误升级
4. 集群扩容脚本里，新节点先通过 curl -s http://seed:5984/ 获取正在运行的 version 字段，再与本机 couchdb -version 输出比对，完全一致才允许加入集群
5. 每周 CI 任务跑 rpm -qi couchdb 与锁定列表交叉校验，结果落库，出现漂移立即飞书告警

这样实现了“包装器、镜像、节点”三轴锁定，可一键回滚，也满足国内金融客户审计要求。

拓展思考

• 蓝绿升级时的版本窗口：CouchDB 3.x 支持滚动升级，但要求“先升级 Minor，再升级 Patch”，且视图索引会在首次访问时重建，如何控制重建时间窗口避免白天高峰？
• 多IDC 同步场景：国内主备两地通过 双向复制同步，若锁定版本后需要回滚，怎样保证回滚期间**复制检查点（checkpoint）**不丢失，避免全量重同步？
• 国产化替代：在麒麟 V10 或 UOS 上，官方仓库没有 CouchDB rpm，需基于源码打 RPM 并自建仓库，此时如何把版本锁定逻辑与 SBOM（软件物料清单） 对接，满足等保 2.0 对开源组件可追溯的要求？