Sharded time series rebuild and resharding
Parent: Bucket fragmentation remediation (re-insert/merge) · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-3a39b842dcf7
↓ Facts as markdownall context files
Source-anchored research for Sharded time series rebuild and resharding. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- The documented resharding flow redistributes collection data through a temporary collection and cutover, while MongoDB's time-series server README describes measurements stored in bucket documents. Neither source promises that resharding coalesces underfilled time-series buckets; whether it reduces bucket fragmentation is an inference that must be measured on the target workload. (medium confidence) [source]
- For a logical rebuild into a time-series collection, MongoDB supports $out starting in 7.0. The migration guide says $out does not guarantee output order, so sort first when order matters, and says to recreate secondary indexes after migration. (high confidence) [source]
- MongoDB Jira records that cloning time-series collections, including through resharding and mongodump/mongorestore, could mis-set the mixed-schema bucket flag for collections created before version 5.2. The issue lists affected versions 6.0.0-6.0.16, 7.0.0-7.0.12, and 7.1-7.3.3, and advises validating affected collections and setting the flag true when needed. (low confidence) (verified as of 2026-10-22) [source]
Measurements and reference values
- MongoDB describes resharding as cloning collection data, building indexes, catching up pending writes, and committing a cutover. Its preparation guide calls for recipient-shard free space of at least 2 × (collection size + index size) divided by the destination shard count, a 24-hour oplog window, I/O below 50%, CPU below 80%, and tolerance for about two seconds of blocked writes. Treat resharding as a planned collection-wide workload. (high confidence) (verified as of 2026-10-23) [source]
- Percona's 2025 benchmark compared resharding an ordinary 3.5 GB people collection on idle two-shard clusters: it reports about three minutes on MongoDB 7.0.18 and under one minute on 8.0.8. The author says larger datasets and loaded clusters need more testing; this is not a time-series benchmark and should not predict time-series reshard duration. (low confidence) (verified as of 2025-06-26) [source]
Problems, failure modes and limitations
- MongoDB documents native time-series resharding starting in 8.0.10, provided every shard in the collection runs 8.0.10 or later. A valid time-series shard key can use the `metaField`, its subfields, the `timeField`, or combinations of those fields. The `timeField` must be ranged and appear last. Shard keys containing the `timeField` are deprecated starting in MongoDB 8.0, and using only the `timeField` is discouraged because its monotonic values may concentrate writes on one chunk. (high confidence) (verified as of 2026-10-20) [source]
- Percona Backup for MongoDB's current logical-restore documentation says sharded time-series collections are not supported. This is a PBM restore limitation and does not establish a MongoDB server limitation or the support status of other backup tools. (low confidence) (verified as of 2026-10-23) [source]
- MongoDB documents an aggregation `$out` workflow for writing measurements into a time-series collection, but `$out` cannot target a sharded collection. It is therefore not a direct rebuild path for a sharded time-series target. (high confidence) (verified as of 2026-10-20) [source]
- Alibaba Cloud's ApsaraDB MongoDB 8 guide says `moveCollection` cannot move time-series collections. That restriction applies to moving an unsharded collection to a shard and is separate from MongoDB's documented `reshardCollection` support for sharded time-series collections. (medium confidence) (verified as of 2026-10-23) [source]
Comparisons and alternatives
- MongoDB Jira issue SERVER-111411 records `forceRedistribution` failing on a time-series collection whose metaField was named `metadata` instead of `meta`. Jira lists fixes in 8.0.28, 8.2.10, and 8.3.0-rc0; the recorded workaround for affected versions was to name the metaField `meta`. Check the patch version before relying on same-key resharding. (medium confidence) (verified as of 2026-07-20) [source]
- As of 2026-10-23, MongoDB Jira marked SERVER-111834 unresolved; it reports that $out into an existing time-series target can recreate the default index even when that index was dropped beforehand. Inspect the post-rebuild index set instead of assuming the previous index state is preserved. (medium confidence) (verified as of 2026-10-23) [source]
- In MongoDB's default viewful time-series implementation, the user-facing collection is a view over `system.buckets`, and queries unpack stored buckets into measurements. The server README also describes viewless time-series collections, so this representation is not universal. MongoDB's `$out` migration guide writes measurement documents to a time-series target, making it a logical-data rebuild rather than a copy of internal bucket documents. (medium confidence) [source]
Facts and statements
- Tencent's MongoDB product guide, last updated 2024-01-15, lists native time-series support and live resharding in separate MongoDB 5.0 subsections. It does not state that MongoDB 5.0 could reshard time-series collections. MongoDB's manual says time-series resharding is supported starting in 8.0.10. (medium confidence) [source]
- MongoDB documents same-key resharding with `reshardCollection` and `forceRedistribution: true` as a way to rewrite a collection and reclaim disk space. Taken together with the time-series support statement, this implies a native same-key rewrite path for eligible sharded time-series collections. The documentation does not promise that this path reduces time-series bucket count or specifically repairs bucket fragmentation. (medium confidence) (verified as of 2026-10-20) [source]
- MongoDB 8.3 documents `rewriteCollection` as rewriting a sharded collection under the same shard key to redistribute data or reclaim disk space. Its command page does not state whether time-series collections are accepted. The time-series limitations page separately documents time-series resharding from version 8.0.10 but does not connect that support statement to `rewriteCollection`. Treat `rewriteCollection` support for time-series as unconfirmed. (low confidence) (verified as of 2026-10-23) [source]
- Percona's 2025 MongoDB 8 resharding overview says its test used a small collection and warns that a terabyte-scale collection may take hours or days in the worst case. This is generic resharding commentary, not a time-series benchmark, so it does not predict a sharded time-series rewrite duration. (low confidence) (verified as of 2025-06-26) [source]
Children
- Logical time-series rebuild with $out (frontier)
- Same-key time-series forceRedistribution (frontier)
- Sharded time-series backup and restore (frontier)
Frontier under this node: Logical time-series rebuild with $out, Same-key time-series forceRedistribution, Sharded time-series backup and restore