PCSM-283 Skip sharding operations for replica set

[rasika-chivate]

Add topology migration from Sharded Cluster to Replicaset.

For details, see the following ticket:

https://perconadev.atlassian.net/browse/PCSM-283

[Copilot]

🟡 Changes recommended

Version guidance, URI syntax, migration prerequisites, and workflow instructions contain unresolved inaccuracies.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (5)

docs/sharding.md:17

• This sentence applies “different numbers of shards” to both target topologies, but a replica set has no shards. Limit that statement to the sharded-target case so the topology description remains accurate.

In both cases, the source must be a sharded MongoDB deployment. The source and target can have different numbers of shards, and a replica set target does not require a target `mongos` instance.

docs/sharded-source-to-replica-set-target.md:41

• The examples are not in one code block, and the stray backtick in target-userbreaks the target username and Markdown rendering. Present both complete environment assignments in a fenced block withtarget-user` intact.

    `PCSM_SOURCE_URI="mongodb://source-user:password@mongos-source:27017/admin"`
    PCSM_TARGET_URI="mongodb://target-`user:password@target1:27017,target2:27017,target3:27017/admin?replicaSet=rs0"`

docs/sharded-source-to-replica-set-target.md:53

• The singular noun after “the other” is missing an article. This also switches from the page's established “target” terminology to “destination”; use a parallel source/target description.

    1. Create two clusters, one sharded (source) and the other replica set (destination).

docs/sharded-source-to-replica-set-target.md:92

• These commands are described as running only on the target, so their output cannot establish that counts match the source. Instruct readers to run the same queries against both deployments before comparing the results.

    6. Confirm that both collections are present on the target and that document counts match:

docs/sharded-source-to-replica-set-target.md:107

• Finalization can still be in progress when the first status request runs (docs/install/usage.md:171-175), so one immediate check is not guaranteed to produce the shown finalized response. Tell readers to poll until that state is reached.

    8. Check the status again:

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

Version guidance, URI syntax, migration prerequisites, and workflow instructions contain unresolved inaccuracies....

Updated the source/target wording, clarified that finalization status should be polled until it reaches finalized, and narrowed the shard-count guidance to the sharded-target case.

[Copilot]

🟡 Changes recommended

Some guidance remains incorrect for replica set targets and filtered replication.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

docs/sharded-source-to-replica-set-target.md:53

• The heading should be capitalized consistently, and the comma after “See” is grammatically incorrect.

## usage

The commands and API endpoints are the same as for any other topology. See, [Percona ClusterSync for MongoDB commands](pcsm-commands.md) for the command reference. 

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

Addressed in 929f26e.

[chupe]

This reads like PCSM checks _id uniqueness which it doesn't. During clone the inserts are unordered and duplicate key errors swallowed. That means some documents might go missing and unreported at that.
During replication an _id collision goes through delete by _id then insert.

Can we make this a prerequisite and a warning instead? _id has to be unique across all source shards, PCSM doesnt verify it. Duplicates are silently dropped or overwritten rather than failing the run.

It could be a pre-migration check too since it might lead to a silent data-loss.

[rasika-chivate]

Fixed.

[chupe]

nit: "For details, see [...] for details."

[rasika-chivate]

Fixed

[chupe]

What are the empty lines for?

[rasika-chivate]

Fixed