Oplog大小无法在线动态调整，必须通过逐个滚动重建副本集成员实现：停止单个节点→清空local目录→用新oplogSizeMB参数重启→自动同步恢复；config server需确保多数派可用，convertToCapped等命令无效。
Oplog大小不能在线动态调整
MongoDB分片集群中，oplog 是每个 mongod 实例（尤其是副本集成员）本地的固定大小集合，存储在 local.oplog.rs。它**不是配置项，而是预分配的 capped collection**——这意味着它的大小在创建时就由初始化参数或启动时自动计算决定，后续无法通过 db.runCommand({collMod: ...}) 或任何运行时命令修改。
常见误解是以为 oplogSizeMB 启动参数可热更新，但实际它只在实例首次初始化或重初始化 oplog 时生效；运行中修改该参数并重载配置（如 mongod --config /path/conf.yaml）不会触碰已有 oplog 的物理尺寸。
唯一可行路径：滚动重建 oplog（不重启整个集群）
要“在线”增大 oplog，本质是让每个 mongod 成员在不中断服务的前提下，用新大小重建自己的 oplog.rs。这只能通过 **逐个移除再重新加入副本集成员** 来达成，依赖副本集的自动数据同步机制：
- 对分片集群中的每个
shard，它本身是一个独立副本集；需对每个 shard 的 secondary 成员依次操作，最后处理 primary（需先执行rs.stepDown()） - 对 config server 副本集（v4.4+ 要求为副本集），同样逐个处理，但必须确保 config server 始终有 majority 可用，否则
mongos将无法路由 - 执行前确认
oplog当前大小：rs.printReplicationInfo()中的configured oplog size字段 - 新
oplog大小由--oplogSizeMB启动参数或配置文件中的replication.oplogSizeMB决定；若未显式指定，MongoDB 会按磁盘空间自动估算（通常 5% of free disk，最小 990MB），不可控
具体操作步骤与关键陷阱
以一个 shard 副本集成员为例（其他副本集同理）：
- 停止目标 secondary 的
mongod进程（不是kill -9，用systemctl stop mongod或mongod --shutdown） - 备份原数据目录（尤其
local/子目录），防止误删 - 清空
local/目录下所有文件（rm -f local/*），但保留目录结构；注意不要删除journal/或_mdb_catalog.wt等非 local 数据 - 用新增的
--oplogSizeMB 4096参数（或其他所需值）重启该节点；此时 MongoDB 启动时检测到local.oplog.rs不存在，会新建一个指定大小的 capped collection - 节点加入副本集后，自动从其他成员同步全量数据 + 增量 oplog，同步完成后状态变为
SECONDARY
⚠️ 容易踩的坑：
-
oplog重建期间，该节点不参与读写，但只要副本集 majority 仍可用，分片集群整体不受影响；若错误地同时停掉多个节点，可能触发选举失败或写不可用 - config server 副本集必须严格保持 3 节点且至少 2 个在线；若仅剩 1 个，
mongos将拒绝写入，整个集群写阻塞 - 重建后务必验证：
db.getSiblingDB("local").oplog.rs.stats().size和.maxSize是否符合预期，而非只看rs.printReplicationInfo()输出
为什么不能用 convertToCapped？
有人尝试用 db.runCommand({convertToCapped: "oplog.rs", size: 4294967296})，这是无效的：
-
local.oplog.rs是系统强制管理的集合，MongoDB 明确禁止对该集合执行convertToCapped、drop、renameCollection等元数据操作 - 执行会直接报错：
"cannot convert system collection local.oplog.rs to capped" - 即使绕过校验强行修改底层 WiredTiger 文件（如编辑
collection-*.wt），也会导致数据损坏或启动失败，完全不可取
真正的“在线”只存在于滚动操作的时间窗口内——每个节点停机时间取决于同步速度，但集群整体服务不中断。别被“动态”二字误导，oplog 大小这件事，没有魔法。
