必须在Primary节点执行mongodump --oplog，因仅Primary实时完整持有local.oplog.rs日志且可写；Secondary的oplog滞后且默认不可读，否则导致oplog.bson无效或报错。
全量备份必须从主节点执行，且 --oplog 不是“增量开关”，而是为后续时间点恢复打基础的必要选项；不加它，备份无法保证一致性。
为什么必须在 Primary 节点上运行 mongodump？
副本集里只有 Primary 节点能接受写入，local.oplog.rs 的最新时间戳和操作日志只在 Primary 上实时完整。如果从 Secondary 执行 mongodump --oplog，会报错或生成无效的 oplog.bson —— 因为 Secondary 的 oplog 可能滞后，且默认不对外提供读取权限（即使开启 readConcern: "majority" 也解决不了 dump 时的 oplog 截断问题）。
- 确认当前主节点：
mongosh --port 27017 -u admin -p pwd --authenticationDatabase admin --eval "rs.isMaster().ismaster"返回true才可继续 - 若不确定哪个是 Primary，先连任意节点执行
rs.status()，找"stateStr" : "PRIMARY"对应的name - 不要用
--host指向副本集名称（如rs0/...）来绕过判断 ——mongodump不支持自动路由到 Primary，它只会连第一个可用节点，风险极高
--oplog 的真实作用和常见误解
--oplog 的本质是：在导出全部数据库数据的同时，把截止到 dump 开始时刻的 oplog 全量拷贝一份到备份目录下（文件名固定为 oplog.bson）。它本身不产生“增量包”，也不会跳过已备份过的数据 —— 每次执行都是全新全量 + 当前 oplog 快照。
- 必须搭配全库备份使用（不能加
-d或-c），否则报错：error: --oplog requires a full dump (no --db or --collection) -
oplog.bson不是差量日志，而是从集群启动或上次 oplog roll-over 后的完整日志集合 —— 它体积可能很大（默认上限 5% 磁盘空间），但mongorestore --oplogReplay只会重放其中从备份时间点之后的部分 - 如果你只想要轻量级备份（比如单个业务库），就别用
--oplog；用了就必须配套--oplogReplay恢复，否则数据和 oplog 时间线对不上
实际可运行的备份命令及关键参数解释
以下命令假设你已在 Primary 节点所在机器上执行，认证库为 admin，用户名 backup_user，密码 secret123，目标路径为 /backup/mongo_20260414：
mongodump \ --host 192.168.100.1:27017 \ -u backup_user \ -p secret123 \ --authenticationDatabase admin \ --oplog \ --gzip \ -o /backup/mongo_20260414
-
--host必须写具体 IP+端口，不能写副本集名；多个节点用逗号分隔仅用于连接发现，不改变 dump 行为 -
--gzip强烈建议加上 —— BSON 压缩后体积通常减少 60%~80%，且mongorestore默认能识别并解压 - 备份目录下会出现：
admin/、config/、test/等子目录（对应各库），以及独立的oplog.bson文件 - 不指定
--db时，local库不会被导出（这是预期行为），因为local是系统库，且含 oplog —— 它已由--oplog单独处理
备份后验证和容易忽略的细节
备份完成不等于可用。真正容易翻车的地方在恢复前的检查环节：
- 用
ls -lh /backup/mongo_20260414/oplog.bson看大小 —— 如果小于 1KB，大概率没拿到 oplog（常见于权限不足或连了 Secondary） - 用
mongodump --version确认工具版本 ≥ MongoDB 6.0 —— 旧版（如 4.x）对 6.0 的 change stream 和新 oplog 格式支持不完整 -
oplog.bson里的时间戳必须覆盖你要恢复的时间点；可通过mongodump --host ... --db local --collection oplog.rs --out - | head -n 20快速查看开头几条记录的"ts"字段 - 备份过程不锁表，但高并发写入下，
mongodump仍可能因网络或磁盘 IO 拖慢主节点 —— 生产环境建议避开业务高峰，并限制速率：--numParallelCollections 2
最常被跳过的一步：没确认 oplog.bson 是否真的包含从备份开始到结束期间的全部变更。一旦缺失，mongorestore --oplogReplay 就会停在某个时间点，导致数据不一致。
