local数据库不参与复制，是各节点独立的私有库，仅用于存储oplog等内部数据；其大小由oplogSizeMB配置决定，非自动增长，且其他集合几乎不占空间，误操作易致副本集瘫痪。
local 数据库不参与复制，所以它在每个节点上都是独立的
副本集里 local 数据库是专供 MongoDB 内部使用的，比如保存 oplog、成员状态、心跳信息等。它不会被复制到其他节点——哪怕你往 local 里写数据，别的节点也完全不知道。这意味着每个节点上的 local 大小可以完全不同，不能拿它来判断同步压力或磁盘使用是否均衡。
常见错误现象：
• 误以为 local 数据库变大说明主从同步卡住了
• 在从节点上手动删 local.oplog.rs 导致复制中断
• 把业务集合建在 local 下，结果切换主节点后数据“消失”
-
local是每个节点私有的，和副本集同步逻辑无关 - oplog 实际存储在
local.oplog.rs（主节点）或local.oplog.$main（4.4+ 默认），但它的大小由oplogSizeMB配置决定，不是自动膨胀的 - 如果启用了
enableMajorityReadConcern: true，local还会额外存一份system.replset和replset.election等元数据，但体积通常很小（KB 级）
oplog 大小直接决定 local 数据库的主存储占比
local.oplog.rs 通常是 local 里最大的集合，占整个数据库 95% 以上空间。它的大小不是按需增长的，而是初始化时就分配好固定大小的 capped collection —— 一旦写满，老数据自动覆盖，所以实际占用磁盘空间基本等于配置值。
使用场景：
• 恢复延迟节点（delayed member）需要足够长的 oplog 保留时间
• 增量备份工具依赖 oplog 时间窗口
• 故障排查时查最近操作日志
- 默认 oplog 大小取决于磁盘空间：64GB 以下机器默认 512MB，64GB 以上默认 1GB —— 但这个值往往不够用
- 建议按「日均写入量 × 保留小时数 × 2」估算，例如每秒写 100 条、保留 24 小时，至少预留 1.7GB（含索引和碎片）
- 调整需重启或用
replSetResizeOplog命令（4.4+ 支持在线调整），但 resize 后不会立即释放磁盘，旧文件要等下次 checkpoint 才清理
local 数据库里的其他集合几乎不占空间，但删错会出大事
除了 oplog.rs，local 下还有 system.replset（当前配置）、startup_log（启动日志）、slaves（已弃用）等。它们都是小集合，加起来一般不到 1MB。但这些是 MongoDB 自己读写的，不能删、不能改结构、不能加索引。
容易踩的坑：
• 用 db.getSiblingDB("local").dropDatabase() 清理磁盘 → 副本集直接瘫痪
• 对 local.system.replset 手动 update → 下次 reconfig 失败，节点无法加入集群
• 误把 local.me 当成可读集合去查 → 实际是 shell 内置变量，不是真实集合
-
local.startup_log是 capped 的，最多存 1000 条，滚动覆盖，不用管 -
local.replset.minvalid记录最小有效 oplog 时间戳，删了会导致该节点拒绝同步 - 所有对
local的写操作（除 oplog 插入外）都绕过复制机制，且不会触发 journal flush，有丢数据风险
预留空间看的是 oplog 分配量，不是 local 总大小
运维时真正要预留的磁盘空间，是 oplogSizeMB 配置值 + 日志和 journal 文件的峰值增长。因为 local 其他部分基本恒定，而 oplog 是唯一可能因突发写入临时撑大的部分（虽然 capped，但 mmapv1 引擎下文件不会收缩，wiredTiger 下也会有 page fragmentation）。
性能影响：
• oplog 太小 → 从节点同步延迟增大，甚至触发 “oplog gap”，必须全量重同步
• oplog 太大 → 启动慢（需扫描更多 oplog）、内存映射压力上升、backup 时间变长
- 检查当前 oplog 大小：运行
db.getSiblingDB("local").runCommand({ "collStats": "oplog.rs" })看size和maxSize - 确认磁盘预留：至少留出
oplogSizeMB × 1.3的连续空间，避免 wiredTiger 因扩展失败卡住 - 不要依赖
db.local.stats().dataSize判断容量水位 —— 它包含大量未回收空间，看fileSize更准
最常被忽略的一点：oplog 的 maxSize 是硬上限，但 wiredTiger 引擎下，local 数据库的实际磁盘占用可能比它高 10%～20%，这是压缩、checkpoint 和内部元数据导致的，监控时得看文件系统层级的 du -sh ./local/，而不是只信 MongoDB 的统计。
