NotMaster错误本质是副本集单主架构强制写操作只能路由至primary节点，secondary节点在协议层直接拒绝写请求，与权限、网络、配置无关。
从节点写入报 NotMaster 错误的本质原因
副本集强制单写多读，所有写操作必须路由到当前 primary 节点。当客户端直连某个 secondary 节点并尝试 insertOne 或 updateOne，驱动会收到 NotMaster 错误——这不是权限或配置问题，而是 MongoDB 内核级的架构约束。
这个错误不是“暂时不可用”，而是“永远不允许”。即使你用 mongosh 手动连上从节点、执行 db.collection.insert({x:1})，结果一样是报错。它和网络、认证、用户角色完全无关。
-
primary是唯一能接受写请求的节点，其他节点在协议层直接拒绝写命令 - 副本集不提供“本地写+异步同步”模式；写入必须先通过主节点落盘，再由 oplog 复制分发
- 驱动（如 Node.js 的
mongodb或mongoose）默认使用readPreference=primary，但不会自动帮你切换连接地址
为什么不能让从节点也支持写入？
允许多点写入会破坏数据一致性模型。MongoDB 的副本集不是多主（multi-master）系统，它的设计目标是强一致的单主复制。如果从节点可写，就立刻引入以下不可解问题：
- 两个节点同时写同一文档的同一字段，谁的版本算“最新”？没有全局时钟或向量时钟机制来协调
- oplog 是线性日志，多写会导致日志无法排序，复制链断裂
- 选举过程中可能出现“双主”窗口，造成数据分裂（split-brain），且后续无法自动合并
- 写关注（
w）语义失效：w: "majority"将失去意义，因为多数节点可能各自写了不同内容
常见误操作：手动指定 secondary 地址后调用 save()
开发者有时为“降低主节点压力”或“就近写入”，在连接字符串里硬编码一个 secondary 的 IP 和端口，比如 mongodb://10.0.1.5:27017/mydb。一旦该节点降级为 secondary，所有写操作立即失败。
这种写法绕过了副本集发现机制，等于主动放弃高可用保障。
- 永远不要在连接字符串中写死单个节点地址，应使用完整的副本集格式：
mongodb://node1:27017,node2:27017,node3:27017/mydb?replicaSet=myrs - 确保应用使用
writeConcern显式控制持久化级别，例如{w: "majority", j: true}，而不是依赖连接地址“选对节点” - 如果确实需要读写分离，应在应用层做逻辑区分：写走统一入口（如负载均衡后的
mongos或primary连接池），读请求才按readPreference分流
磁盘满导致从节点看似“可写但失败”的假象
当副本集某节点磁盘空间耗尽，它可能仍处于 secondary 状态、能响应心跳和读请求，但实际已无法追加 oplog 或应用复制数据。此时你连上去执行写操作，会收到 not authorized on xxx to execute command 这类看似权限错误的信息——其实是底层存储拒绝写入的伪装提示。
真正的问题不在角色，而在磁盘。这类场景下，rs.status() 可能看到 stateStr: "SECONDARY"，但 optimeDate 停滞、lastHeartbeatMessage 提示 disk space exhausted。
- 检查每个节点的磁盘使用率，不只是
primary；secondary磁盘满也会导致复制中断，间接引发写失败 - 监控项优先看
db.stats().dataSize+db.stats().fileSize与磁盘剩余空间的比值，而非仅依赖系统 df - WiredTiger 日志文件（
journal/目录）膨胀常被忽略，它不计入db.stats()，却会快速占满磁盘
副本集的“只读从节点”不是功能缺陷，而是为保证线性一致性和故障恢复能力所付出的明确取舍。最易被忽略的一点是：**写操作的可用性，永远取决于整个副本集的健康度，而不仅是 primary 节点本身的状态**。
