# Sharded time series rebuild and resharding > Source-anchored research for Sharded time series rebuild and resharding. Run status: COMPLETED. Parent: [Bucket fragmentation remediation (re-insert/merge)](https://llms-explorer.com/tree/bucket-fragmentation-remediation-re-insert-merge/) · 5 facets · 16 facts · page: https://llms-explorer.com/tree/sharded-time-series-rebuild-and-resharding/ ## 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](https://www.mongodb.com/docs/manual/tutorial/resharding-for-adding-and-removing-shards/) - 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](https://www.mongodb.com/docs/v8.3/core/timeseries/timeseries-migrate-with-aggregation/) - 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](https://jira.mongodb.org/browse/SERVER-91194) ## 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](https://www.mongodb.com/docs/manual/core/sharding-reshard-a-collection.md) - 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](https://www.percona.com/blog/scaling-smarter-what-you-have-missed-in-mongodb-8-0/) ## 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](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-limitations/) - 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](https://docs.percona.com/percona-backup-mongodb/latest/usage/restore.html) - 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](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-migrate-with-aggregation/) - 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](https://help.aliyun.com/en/mongodb/product-overview/features-of-mongodb-8-0) ## 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](https://jira.mongodb.org/browse/SERVER-111411) - 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](https://www.mongodb.com/docs/v8.3/core/timeseries/timeseries-migrate-with-aggregation/) - 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/timeseries/README.md) ## 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](https://main.qcloudimg.com/raw/document/intl/product/pdf/240_620_en.pdf) - 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](https://www.mongodb.com/docs/manual/core/reshard-to-same-key/) - 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](https://www.mongodb.com/docs/v8.3/reference/command/rewritecollection/) - 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](https://www.percona.com/blog/scaling-smarter-what-you-have-missed-in-mongodb-8-0/)