PCSM-330 Multiple PCSMs against the same source

[rasika-chivate]

No description provided.

[Copilot]

🟡 Changes recommended

Multiple documentation errors could produce broken rendering or incorrect deployment instructions.

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

Pull request overview

Adds guidance for replicating filtered namespaces from one source cluster to multiple targets.

Changes:

• Documents replica-set and sharded-cluster workflows.
• Adds verification examples and navigation.

Required fixes in docs/multiple-targets.md:

• Moderate (line 43): Indent the three code fences beneath the numbered-list tab.
• Nit (line 19): Specify execution context and unique ports for co-located instances.
• Moderate (lines 45, 53): Include all replica-set members in source and target URIs.
• Moderate (lines 79, 223): Wait for cloning to finish and replication lag to become acceptable, not for real-time replication to “complete.”
• Moderate (line 231): Indent command blocks beneath steps 6 and 7.
• Moderate (line 315): Align the closing fence with its opening fence.

File summaries

File	Description
mkdocs-base.yml	Adds the guide to navigation.
docs/multiple-targets.md	Documents multi-target replication workflows.

Review details

Suppressed comments (2)

docs/multiple-targets.md:54

• This second replica-set startup repeats the single-seed URI, despite docs/install/authentication.md:52-56 requiring all replica-set members in each connection string. Include every member of rs1 and rs3 so this instance is not dependent on one host being reachable.

                --source "mongodb://csync:<password>@rs101:27017/?replicaSet=rs1" \
                --target "mongodb://csync:<password>@rs301:27017/?replicaSet=rs3"

docs/multiple-targets.md:223

• As in the replica-set flow, the continuous replication stage never completes on its own; only finalization stops it. Define the readiness condition as clone completion plus acceptable replication lag so users know when to proceed.

    5. Check each instance and wait for the clone and replication stages to complete:

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

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

The replication procedure specifies an unattainable completion condition that must be corrected before approval.

Review details

Suppressed comments (2)

docs/multiple-targets.md:21

• This standalone workflow invokes pcsm start in both tabs without first warning that the selected target collections are dropped and recreated. The primary usage guide explicitly treats this as destructive (docs/install/usage.md:13-14); add the warning here before readers can overwrite existing db_0 or db_1 data while following the example.

The examples below replicate `db_0` to the first target and `db_1` to the second. Select the tab that matches your deployment.

docs/multiple-targets.md:223

• The real-time replication stage does not complete before finalization; it continues consuming source changes until finalize stops it. Waiting for both the clone and replication stages to “complete” therefore gives readers no achievable status condition and can stall this procedure indefinitely. Use the concrete clone-complete and acceptable-lag criteria already given in the replica-set tab.

    5. Check each instance and wait for the clone and replication stages to complete:

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