Sizing the Oplog Window, Not Just the Dataset
MongoDB's oplog is a capped collection that every secondary replays to stay in sync — size it too small and a secondary that falls behind (a slow disk, a maintenance window, a network partition) can no longer catch up because the entries it needs have already been overwritten. This calculator computes oplog size directly from sustained write throughput: writeThroughputMB × 3600 × oplogWindowHours, i.e. the total bytes written during however many hours of replication lag you want to survive (default: 48 hours at 50MB/s ≈ 8.4TB of oplog). It separately estimates index overhead at a flat 15% of dataset size — a rule-of-thumb ratio, not a measured figure, since actual index size depends heavily on field cardinality and compound index design.
Sharding and the >500GB Warning
- Shard count:
minShards = ceil(dataSizeTB ÷ maxShardSizeTB)— a hard floor, not accounting for uneven chunk distribution across shard keys, which in practice can leave some shards far fuller than others. - The oplog resize gotcha: Oplog size is set once at replica set initialization; changing it later on a live deployment requires
replSetResizeOplog, not just a config edit and restart. - Why the 500GB flag exists: An oplog that large usually signals the write throughput or lag window inputs are unrealistic for a single replica set, and it's a strong hint to shard sooner or reduce the target recovery window instead of just provisioning more disk.