题干与适用场景
团队计划从 PostgreSQL 18 升级到 PostgreSQL 19。现有集群使用 RADIUS 和部分 MD5 密码认证，客户端包括应用、运维脚本和 BI 工具。请说明如何盘点依赖、选择替代认证、验证客户端并设置停止条件。
PostgreSQL 官方的 19 Beta 说明这是预发布功能预览，不建议直接用于生产。19 的迁移说明移除了 RADIUS 支持，并会在成功的 MD5 认证后发出警告；RADIUS 仅支持 UDP，官方说明其安全性无法修复。题目考察认证迁移的证据链，不要求假设所有环境都受影响。
面试官考察点
面试官会关注你是否区分认证协议移除、密码存储格式和客户端能力，能否建立完整依赖清单、最小权限替代方案、可观测灰度与明确回滚。高质量回答还会说明 Beta 结论不能等同于最终版承诺，并避免把 MD5 警告误说成已经禁止连接。
回答前需要澄清的问题
- 当前 PostgreSQL 版本、目标版本和计划中的正式版时间是什么？
- 哪些入口使用 RADIUS，哪些用户或连接仍使用 MD5？
- 客户端驱动、连接池、运维工具是否支持 SCRAM、证书或外部身份代理？
- 认证服务器、网络路径、审计要求、故障转移和应急账号如何管理？
- 迁移期间允许的中断时间、回滚窗口和安全负责人是谁？
30 秒回答
“我先把 Beta 当作隔离验证对象，盘点所有 pg_hba.conf 规则、用户密码格式、客户端和 RADIUS 依赖，再在 PostgreSQL 19 测试集群验证 SCRAM、证书或受控身份代理。先让同一身份同时具备新旧路径，在无写入生产的环境回放连接、故障转移和审计场景；逐步切换低风险租户，观察认证失败、延迟和审计缺口。任何无法登录、权限扩大、审计缺失或回滚失败都停止，并保留旧集群和旧认证路径。”
分步骤深入解答
1. 先建立依赖清单
导出并评审 pg_hba.conf、角色属性、密码存储方式、连接来源、客户端版本、连接池和自动化脚本。把 RADIUS、MD5、SCRAM、证书和外部代理分别标记，记录每条规则的用户、网段、数据库、优先级和责任人。不要只搜索应用仓库，因为临时脚本和 BI 工具也可能持有连接凭据。
2. 区分移除与警告
PostgreSQL 19 的迁移说明移除了 RADIUS；成功的 MD5 认证会触发客户端警告，且可通过 md5_password_warnings 控制。警告表示仍需迁移，不等同于当前连接已经被拒绝。RADIUS 依赖必须在升级前替换，MD5 依赖则要安排密码和规则迁移，避免把两种风险混为一谈。
3. 选择替代认证并限制权限
优先评估 SCRAM-SHA-256、客户端证书或已有企业身份代理，具体选择取决于客户端支持、密钥生命周期、网络边界和审计要求。为迁移建立短期、最小权限账号，禁止共享超级用户；新旧账号分离，设置过期时间和负责人。认证方案要能覆盖故障转移、只读副本、运维 break-glass 账号和离线恢复。
4. 在隔离环境验证连接矩阵
用脱敏数据和独立凭据复制生产拓扑，逐项验证应用、连接池、迁移工具、备份恢复、监控和故障转移。为每种客户端固定驱动版本，记录认证方式、TLS、连接耗时、失败原因和审计事件。可以先让同一角色存在新旧登录路径，但禁止让测试凭据访问生产。
psql "host=pg19-test dbname=app user=app_scram sslmode=verify-full" -c 'select 1'
psql "host=pg19-test dbname=app user=app_cert sslmode=verify-full" -c 'select 1'5. 设计灰度、闸门与回滚
先切换低风险租户或非关键作业，再扩大范围。设置认证失败率、连接延迟、密码重置成功率、审计事件完整率和故障转移成功率的阈值；任何权限扩大、无法登录、审计缺口或恢复失败立即停止。保留 PostgreSQL 18 的可启动副本、旧规则版本、密码轮换记录和回滚脚本，并验证旧客户端仍能在回滚窗口内恢复。
6. 记录 Beta 的不确定性
Beta 版本的行为和接口仍可能变化。把测试结论写成“在某客户端、某认证配置和某测试数据上的结果”，记录版本、配置哈希和已知问题；等待正式版再做最终批准。不要因为测试集群成功就声称所有客户端都兼容。
高质量示范回答
我会先冻结 PostgreSQL 18 的认证基线，导出 pg_hba.conf、角色、客户端和 RADIUS 依赖，按入口和责任人建立矩阵。由于 PostgreSQL 19 移除 RADIUS，我会在隔离集群为受影响身份验证 SCRAM、证书或企业身份代理，并单独处理仍使用 MD5 的用户；MD5 成功认证警告说明要迁移，不表示已经全面拒绝。随后回放应用、连接池、脚本、备份恢复和故障转移，观察失败率、延迟、审计和权限边界。低风险灰度通过所有闸门后才扩大；出现权限扩大、审计缺失、无法登录或回滚失败就停止并恢复旧路径。Beta 证据只作为正式版评估输入。
常见错误
- 把 RADIUS 移除和 MD5 警告当成同一件事 → 一个是支持移除，一个是迁移信号 → 分别盘点和设定计划。
- 只改
pg_hba.conf不测客户端 → 驱动和连接池可能不支持新方式 → 建立完整连接矩阵并逐项回放。 - 直接在生产轮换全部密码 → 故障面和回滚难以控制 → 先做隔离验证、短期最小权限账号和分批切换。
- 忽略 break-glass 账号 → 故障时可能无法恢复 → 准备受控应急账号、双人审批和审计。
- 把 Beta 测试通过写成最终兼容承诺 → 预发布行为仍可能变化 → 记录版本与边界，正式版重新批准。
追问及应对
什么时候必须停止升级？
出现无法登录、权限扩大、审计缺口、关键客户端不兼容、故障转移失败或回滚无法在窗口内完成时停止。
为什么不能只把 RADIUS 替换成任意密码认证？
认证强度、密钥生命周期、网络边界和审计要求可能不同；替代方案必须满足组织安全策略并覆盖客户端与故障场景。
MD5 警告是否意味着马上断开所有 MD5 用户？
不是。警告用于暴露仍在使用的路径；应先识别客户端、轮换密码并验证 SCRAM、证书或代理路径，再按窗口分批切换。
如何证明没有遗漏隐藏客户端？
结合连接日志、审计、角色使用记录、网络来源、仓库搜索和运维访谈，按时间窗口核对矩阵；迁移前后持续监控未知来源和认证失败。
Beta 验证通过后何时可以生产？
等正式版发布，重新验证版本和客户端矩阵，完成回滚与审计演练，并由安全、数据库和业务负责人共同批准后再灰度。