rs.remove()仅移除副本集配置中的节点条目，不关闭服务、不清除数据；需先停mongod、确认节点状态、正确指定host:port，并确保连接主节点且权限足够。
rs.remove() 会直接删掉节点配置，但不关服务也不清数据
执行 rs.remove() 只是把目标节点从副本集配置里踢出去，MongoDB 不会帮你停 mongod 进程、不删数据目录、也不动系统服务。如果节点还在跑，它可能继续尝试拉取 oplog 或报错连不上其他成员，甚至在某些网络分区场景下悄悄重新加入（比如配置没及时同步到所有节点）。
实操建议：
- 先确认目标节点状态：用
rs.status()看它的stateStr是不是SECONDARY或ARBITER；别对PRIMARY直接rs.remove()，先降级 - 执行前在目标节点上手动停服务：
sudo systemctl stop mongod（或mongod --shutdown），避免残留连接干扰 -
rs.remove()的参数必须是完整 host:port 字符串，比如"node3.example.com:27017"，不能只写主机名或 IP（除非 DNS 解析完全可靠） - 执行后立刻在其他节点上运行
rs.conf()，确认配置版本（version）已递增，且该节点条目消失
PRIMARY 节点不能直接 remove，得先 stepDown 再操作
试图对当前主节点调 rs.remove() 会失败，报错 not master 或 can't remove primary。MongoDB 强制要求主节点必须主动让位，否则副本集无法维持法定人数（majority）和写入可用性。
实操建议：
- 用
rs.stepDown(60)让主节点自愿退位，参数是秒数（至少 60 秒，防止立即又被选上） - 等
rs.status()显示原 PRIMARY 变成SECONDARY后再执行rs.remove() - 如果副本集只有 3 个节点，移除一个后剩下 2 个，法定人数变成 2 —— 这时任意一个宕机，整个集就不可写。提前评估是否要加仲裁节点或调整写关注（
w） - 别在维护窗口外做
stepDown，它会导致短时写入中断（通常几秒），应用可能收到NotMaster错误
移除后残留的 local 数据库不会自动清理
即使 rs.remove() 成功，目标节点上的 local 数据库（含 oplog.rs、system.replset）仍完整保留。下次误启 mongod 且配置没改，它可能以旧身份尝试重连，导致配置冲突或日志刷屏警告。
实操建议：
- 移除节点后，登录该机器，进 mongo shell 清空 local 库：
use local→db.dropDatabase() - 更彻底的做法是删整个数据目录（如
/var/lib/mongodb），但前提是确认没混用其他用途的 collection - 检查
/etc/mongod.conf里的replSetName和bindIp，建议注释或删掉 replica set 相关配置，避免重启后自作主张加入集群 - 如果节点后续要复用为新副本集成员，必须重初始化：删数据目录 + 改配置 +
rs.initiate()，不能沿用旧数据
rs.remove() 失败常见原因和快速排查路径
最常见的失败不是语法错，而是配置没同步或权限不足。错误信息像 not master and slaveOk=false 或 not authorized on admin to execute command 往往让人误以为是网络问题，其实根源在会话上下文或用户角色。
实操建议：
- 确保连接的是当前 PRIMARY 节点（
rs.isMaster().ismaster === true），别连 secondary 执行rs.remove() - 认证用户必须有
root或clusterAdmin角色，普通readWrite权限不够 - 检查
rs.conf()输出里目标节点的_id是否和你要删的匹配；有时 host 名拼写差一个点（node3.example.comvsnode3.example.com.）也会失败 - 如果副本集启用了
sslMode: requireSSL，客户端连接也必须带证书，否则rs.remove()会静默失败或超时
最麻烦的其实是网络抖动导致配置变更没落地——操作完立刻查 rs.conf() 比看返回值更可靠。另外，跨大版本升级（比如 4.4 → 6.0）后移除节点，记得先统一所有节点的 featureCompatibilityVersion，否则配置更新可能被拒绝。
