19已不再支持RADIUS认证。旧环境若用pg_hba.conf里的radius规则登录，需要在升级前安排替代方式；原样复制旧配置不能恢复被移除的支持。

应用账号和员工账号不一定要采用相同方案。前者可评估SCRAM，后者应结合现有身份系统考虑GSSAPI、LDAP、证书等方式，先弄清需求与实际使用范围。

一、为什么移除，哪些系统受影响？

原来的PostgreSQL RADIUS实现只支持UDP，发布说明指出其安全问题无法在原实现中妥善修补。因此这不是改一个默认参数就能重新开启的能力。

影响范围取决于实际匹配到的登录规则。业务程序、数据库管理员、报表工具、定时任务，只要通过 radius 认证，都要纳入迁移。反过来，数据库所在公司使用 RADIUS，并不代表 PostgreSQL 本身一定使用了它。

二、先查规则，再找使用者

由有权限的管理员在旧库检查文件位置和解析结果：

还要查看引用的配置文件和实际登录日志。规则视图展示的是当前磁盘上的文件内容，不一定就是服务器最后成功加载的内容；只看文件没有报错，不代表连接已按预期使用新方式。

整理出账号、来源地址、客户端版本和负责人。尤其别漏掉一个月才运行一次的任务，以及只在故障时才使用的管理员账号。

三、替代方案怎么选？

不要仅仅把 radius 这个单词换成 scram-sha-256。原来的外部认证口令，不会自动成为数据库内部可用的 SCRAM 口令。用户是否已有数据库口令、客户端从哪里取得它，都需要明确。

四、应用账号迁到 SCRAM，可以怎么安排？

先在测试环境确认驱动和连接池支持 SCRAM，然后为测试账号设置 SCRAM 口令。使用 psql 时，可以在管理员会话中设置生成方式，再交互式修改口令：

接着为这个账号和明确来源网段配置新规则。下面只是格式示例，实际数据库、账号和网段要按环境填写；hostssl 还要求服务器已经正确配置 TLS：

保持能够管理数据库的有效连接，先检查文件错误，再按部署方式重载配置。新开一条真实客户端连接测试，不能用已有连接未断开来证明迁移成功。

五、切换时最容易忽略什么？

登录规则从上往下使用第一条匹配项。前面的宽泛旧规则可能挡住后面的新规则，而且认证失败后也不会继续尝试下一条。

逐组迁移更容易定位异常：先验证账号，再少量应用，最后覆盖其他客户端。观察新连接、认证耗时和后台任务；仍用外部身份服务时，还要验证服务故障的影响。

真实客户端验证通过后，再从目标配置清掉radius内容并演练升级。迁移完成的依据，是新连接确实通过新方式认证，而不只是文件里的名称已经改了。