SPM-2419 originally envisioned per-shard change streams & document cursors to support mongosync.

The C2C initiative later decided to partition collections by _id, which obviated per-shard document cursors. Thus, SPM-2419 was closed with only per-shard change streams delivered.

C2C eventually found several migrations where random _id values made _id partitioning untenable. As a result, mongosync implemented $natural scans.

Mongosync's $natural scan support, however, is currently not resumable nor parallelizable. Thus, if mongosync fails, the collection scan has to restart from the beginning. We can fix this for unsharded sources, but not for sharded sources because we can't partition along record IDs through a mongos.

Mongosync can resume $natural scans today, but only from unsharded clusters. To make sharded collection scans resumable & parallelizable in mongosync, then, the server would need to implement a passthrough `find` so mongosync can query individual shards (and individual nodes).

Intended workflow

1. Open a cursor on a given shard. Ideally we’d like the flexibility to read from either a primary or secondary.
2. If we resume the cursor after a crash, the `find` must target the original node. (Resume tokens in 8.0+ enforce this.)

About replicated record IDs (SPM-4519)

Per a DM with henrik.edin@mongodb.com: there will be an upgrade procedure for existing data. This will likely be opt-in, though, for on-prem customers. Thus we can’t rely on it.