rs.addArb()不能直接加IP:端口，因其必须在Primary节点执行，且参数必须是rs.conf()中已声明的host值，而非任意可达地址；仲裁节点需禁用journal和oplog，启动前须清理数据目录并显式配置arbiterOnly:true。
rs.addArb() 为什么不能直接加 IP:端口？
直接执行 rs.addArb("10.0.1.5:27017") 很可能报错 not master 或 no reachable servers——因为 rs.addArb() 必须在当前 Primary 节点上运行，且传入的必须是副本集中已配置的 host 字符串（即 rs.conf() 中 members[n].host 的值），不是任意可达地址。
常见错误场景：仲裁节点刚启动，但未在配置中声明；或用了 NAT 后的公网 IP，而副本集内部用的是内网 DNS 名。
- 先连到 Primary（用
rs.status().myState === 1确认） - 查当前配置：
rs.conf().members.map(m => m.host)，确保你要加的 host 已出现在列表里（哪怕状态是DOWN） - 若没出现，得先
rs.add({host: "arbiter-host:27017", arbiterOnly: true})，再用rs.addArb()
仲裁节点必须关闭 journal 和 oplog 吗？
是的，否则浪费资源且可能干扰选举。仲裁节点不存储数据，不需要持久化写操作，journal 和 oplog 不仅无用，还会拖慢启动、占用磁盘，并在某些版本中导致 startupWarnings 报告“oplog size too small”。
启动仲裁节点时，务必显式禁用：
- 配置文件中设
storage.journal.enabled: false和replication.oplogSizeMB: 0 - 命令行启动加
--nojournal --oplogSize 0 - 验证是否生效：
db.adminCommand({getCmdLineOpts: 1})查parsed.storage.journal.enabled
rs.addArb() 后选举没立刻稳定？检查 heartbeatTimeoutMillis
添加仲裁节点后，可能出现短暂的 SECONDARY → ARBITER → UNKNOWN 循环，甚至 Primary 主动降级。这往往不是配置错误，而是心跳超时太短，新节点尚未完成握手就被标记为不可达。
rs.conf() 中默认 settings.heartbeatTimeoutMillis 是 10000（10 秒），但在高延迟网络或负载重的仲裁节点上不够用：
- 临时调高：在 Primary 上运行
rs.reconfig({ _id: "rs0", version: X+1, members: [...], settings: { heartbeatTimeoutMillis: 30000 } }) - 注意：version 必须比当前
rs.conf().version大 1，否则报InvalidReplicaSetConfig - 仲裁节点本身不参与投票权重计算，但它的在线状态会影响法定票数（majority）达成速度
为什么 rs.status() 里 arbiterOnly 是 true，但节点仍被当成 data-bearing？
典型表现：该节点在 rs.status().members[n].stateStr 显示 STARTUP2 或 RECOVERING，而不是预期的 ARBITER。根本原因是它被错误地初始化过数据目录——哪怕只启动过一次没加 --arbiterOnly，MongoDB 就会创建 local 数据库和 oplog，后续再加 arbiterOnly: true 也无效。
修复方式只有彻底清理：
- 停掉该节点进程
- 删除整个数据目录（如
/var/lib/mongodb） - 重启时明确加
--arbiterOnly参数，或配置文件中设replication.arbiterOnly: true - 再从 Primary 执行
rs.addArb()
这个步骤没法跳过，任何“热修复”尝试都会让节点卡在非终态。
