MongoDB 5.3+ 默认禁止多个仲裁节点，因其破坏w:"majority"写安全：总投票数含仲裁，但数据节点不足时，写入可能仅被主节点和仲裁确认而未同步到从节点即丢失；单仲裁仍合法，须独立部署且不可与主从共机。
arbiterOnly 必须设为 true，且不能与数据节点共存于同一物理机 —— 这是配置仲裁节点最核心、最容易被跳过的硬性约束。
配置 arbiterOnly: true 是唯一生效方式
仲裁节点不是靠启动参数或角色命名自动识别的，而是由副本集成员配置中的 arbiterOnly 字段决定。即使你把 mongod 进程单独部署、不配 dbpath，只要没在 rs.reconfig() 里显式设置 "arbiterOnly": true，它就仍是普通数据节点（哪怕实际没写入任何数据）。
常见错误：只改了 priority: 0 或 votes: 1 就以为是仲裁节点 —— 这些字段不影响身份判定，仅影响投票权重和选举资格。
-
arbiterOnly: true会强制该成员不拉取 oplog、不同步数据、不响应读请求 - 必须搭配
votes: 1（默认值），否则它连投票权都没有 -
priority: 0是推荐但非必需的，防止意外被选为主节点
绑定地址和防火墙必须允许跨节点通信
仲裁节点虽不存数据，但仍需与主从节点建立 TCP 连接参与心跳和投票。如果 net.bindIp 只写了 127.0.0.1，或者防火墙没放开 MongoDB 端口（如 27017），它会一直卡在 STARTUP2 状态，rs.status() 显示 "stateStr" : "ARBITER" 前始终是 "UNKNOWN" 或 "DOWN"。
- 检查
mongod启动日志，确认有类似listening for connections on port 27017且绑定的是实际网卡 IP（如192.168.1.85），而非仅127.0.0.1 - 用
telnet 主节点IP 27017从仲裁节点机器测试连通性 - 确保主从节点的
replSet配置中包含仲裁节点的完整host（如"host": "192.168.1.85:27017"）
添加仲裁节点必须执行 rs.reconfig() 而非直接启动
仲裁节点不是独立服务，它必须被正式加入副本集配置才能参与投票。单纯启动一个带 --replSet 参数的 mongod 进程，它只是个“游离”实例，不会自动注册进现有副本集。
- 先在主节点上运行
rs.add({host: "192.168.1.85:27017", arbiterOnly: true}) - 若已有配置对象，需用
rs.reconfig()全量替换（注意递增version字段） - 执行后立刻查
rs.status().members，确认新成员stateStr变为"ARBITER"，且health为1 - 不要在
rs.reconfig()中同时修改多个成员，尤其避免改动主节点配置，易触发不必要的选举
5.3+ 版本禁止多个仲裁节点，且默认拒绝非法配置
MongoDB 5.3 起，服务端直接校验 arbiterOnly 成员数量，超过一个就报错：MongoServerError: Multiple arbiters are not allowed。这不是警告，是硬性拦截 —— 即使你手动构造配置文档并调用 rs.reconfig()，也会失败。
- 旧版本（如 4.4）虽允许，但会导致
w: "majority"写关注不可靠：当一个数据节点宕机，剩余一个数据节点 + 多个仲裁节点时，“多数”可能仅含仲裁节点，写操作仍成功但无实际数据落盘 - 生产环境务必保证
votes总数为奇数，且arbiterOnly成员数 ≤ 1 - 若误加第二个仲裁节点，需先移除再重试：
rs.remove("host:port")
arbiterOnly 没设、bindIp 写错、或者版本升级后没清理掉历史冗余配置。 
