副本集启动失败是因为缺少内部认证配置；scram仅用于客户端认证，节点间通信必须使用keyfile或x.509，仅启用security.authorization: true会导致recovering状态及“no valid authentication mechanism”错误。
副本集不能直接用 SCRAM 做成员间内部认证——这是常见误解的根源。SCRAM 只用于客户端连接的身份验证，副本集节点之间的通信必须用 keyFile 或 X.509。如果你试图只开 security.authorization: true 就想让副本集跑起来，会卡在 RECOVERING 状态，日志里反复报 no valid authentication mechanism。
为什么副本集启动失败？检查是否漏了内部认证配置
副本集成员（mongod）之间需要相互认证才能同步数据、选举主节点。仅启用客户端 SCRAM（即只设 security.authorization: true）完全不够，系统根本不会尝试建立复制连接。
- 必须通过
security.keyFile或security.tls.mode: requireTLS+security.tls.CAFile+security.tls.certificateKeyFile配置内部认证 -
keyFile是最简方案：所有节点共用同一文件，内容为 base64 字符串（6–1024 字符），且文件权限必须是600（Linux/macOS） - 如果用了
keyFile，security.authorization可以同时开启，两者不冲突；但没keyFile就绝不可能完成初始化
如何安全添加 SCRAM 用户（避免权限错配）
用户必须在 admin 数据库创建，且角色绑定要严格匹配用途。用错数据库或角色会导致连接成功但无法读写任何集合。
- 先用
mongosh --port 27017连未启用 auth 的实例（或利用 localhost exception） - 执行
use admin后调用db.createUser()，pwd务必用passwordPrompt()，别硬编码明文密码 - 普通应用用户至少需
{ role: "readWrite", db: "myapp" }；管理用户才给userAdminAnyDatabase - 创建后立即测试：
mongosh "mongodb://myuser:pass@localhost:27017/myapp?authSource=admin"
启动参数和配置文件的关键差异
命令行和 YAML 配置对认证机制的生效逻辑不同，混用容易遗漏项。
- 命令行启动必须显式加
--keyFile /path/to/keyfile和--authorization，缺一不可 - YAML 配置中，
security.keyFile和security.authorization: true必须同级存在，且keyFile路径需绝对路径 - 如果用 systemd 管理服务，确保
mongod.service的User=和keyfile所有者一致，否则报Permission denied - 修改配置后务必执行
mongod --config /etc/mongod.conf --shutdown再重启，直接 kill -9 不触发 clean shutdown 可能损坏 oplog
真正容易被忽略的是：密钥文件内容看似简单，但换行、空格、BOM 字符都会导致节点拒绝加入副本集，且错误日志只提示 authentication failed，不会指出是密钥解析失败。建议用 base64 -w 0 /dev/urandom | head -c 1024 > keyfile 生成，然后 chmod 600 keyfile 并 scp 到所有节点再校验 sha256sum。
