主备切换后权限认证失效的核心原因是元数据未同步到位，需逐层定位认证链路断点，比对各节点用户表、凭证哈希、角色权限等关键元数据是否一致，并优先用快照同步而非重创建修复。

主备切换后权限认证失效，不是配置写错了，而是元数据没同步到位。核心思路是：先确认认证失败发生在哪一环，再逐层检查各组件的权限/用户/密钥状态是否一致。

查清认证链路中的“断点”在哪

权限认证通常涉及多个环节：客户端 → 负载设备（如AC、防火墙）→ 认证服务器（如RADIUS、LDAP）→ 后端数据库（如MongoDB、SQL Server）。切换后失效，要先定位失败发生在哪一级：

• 如果连不上服务（如Connection refused），优先查网络、端口、进程状态
• 如果提示“Authentication failed”“Invalid credentials”“Shared secret mismatch”，说明已抵达认证服务，但校验失败——重点查密钥、用户表、凭证哈希
• 如果登录成功但执行操作被拒（如SELECT denied），说明认证通过但授权缺失——查角色、权限作用域、元数据是否同步

逐节点比对关键认证元数据

很多系统（如MongoDB、PostgreSQL Patroni、SQL Server AlwaysOn）默认不自动同步用户和权限元数据。切换后新主节点可能有完整配置，但旧主或从节点仍用旧快照：

• MongoDB：直连每个副本集节点，运行db.getSiblingDB("admin").system.users.countDocuments({})，再比对各用户credentials.SCRAM-SHA-256.storedKey和roles数组内容是否完全一致
• SQL Server AlwaysOn（2022前）：检查master.sys.server_principals、msdb.dbo.sysjobs等系统表在各副本上是否存在且状态一致；作业不会自动迁移，需手动启用或加判断逻辑
• RADIUS对接设备（如AC6508）：确认主备AC配置的shared-key与RADIUS服务器侧完全相同，大小写、空格、特殊字符都不能差

验证认证上下文是否匹配

MySQL、Oracle、Kingbase等常因host、service name、密码文件不一致导致切换后认证失败：

• MySQL：执行SELECT USER(), CURRENT_USER();，看连接声明的身份和实际匹配的账户是否一致；检查mysql.user中对应(user, host)是否存在，注意localhost ≠ 127.0.0.1
• Oracle ADG：主备切换后若提示用户名密码错误，很可能是密码文件orapw$ORACLE_SID未同步到新主，需在新主节点重建并确保REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
• H3C IRF堆叠：执行display irf verbose，确认Configuration Synchronization和State Synchronization均为Completed，否则权限配置无法生效

修复与预防建议

临时修复要快，长期稳定靠机制：

• 修复时避免在节点上单独运行CREATE USER，优先用mongodump/mongorestore或pg_dump/pg_restore同步元数据快照
• 所有密钥（RADIUS shared-key、数据库密码文件、TLS证书）必须纳入配置管理工具（Ansible/Terraform），禁止人工维护
• 把用户创建、角色分配、作业启停等操作固化进集群初始化脚本，每次部署/扩容都重放，不依赖“上线后再补”
• 切换演练必须包含权限验证环节：模拟真实业务账号登录+执行典型操作，不能只测连通性