PCSM-330 Multiple PCSMs against the same source - #70
rasika-chivate wants to merge 32 commits into
Conversation
Render
Destroyed
Render
Destroyed
There was a problem hiding this comment.
🟡 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-56requiring all replica-set members in each connection string. Include every member ofrs1andrs3so 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.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Render
Destroyed
Render
Destroyed
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Render
Destroyed
Render
Destroyed
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Render
Destroyed
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>
| If the source collection was sharded, confirm that the target collection is sharded too. | ||
|
|
||
| !!! note "Chunk distribution differs by design" | ||
| PCSM replicates data, not sharding metadata. The shard key comes across, but chunk distribution and the primary shard are decided by the target cluster and its balancer, so they will not match the source. A different layout here is expected and does not indicate a problem. See [Chunk distribution](sharding.md#chunk-distribution). |
There was a problem hiding this comment.
this needs to be changed since we now copy initial chunk distribution with PCSM
|
|
||
| ## Check the logs | ||
|
|
||
| Every instance logs separately, so check each one for errors before you decommission the source or send traffic to a target. Command responses go to `stdout` and logs and errors go to `stderr`. See [Logging in Percona ClusterSync for MongoDB](logging.md). |
There was a problem hiding this comment.
This describes client subcommands, but the paragraph is about server logs. The PCSM server writes logs to stdout, while client subcommands write logs and errors to stderr. Can we distinguish those here?
| 6. Finalize each instance. PCSM stops replication, creates the remaining indexes on the target, and exits: | ||
|
|
||
| ```bash | ||
| pcsm finalize | ||
| ``` |
There was a problem hiding this comment.
pcsm finalize initiates finalization and returns while index creation continues. We should always make it clear that actual state of the PCSM server is best viewed via pcsm status.
The sharded example should also tell readers to check unsuccessfulIndexes for consistency with the replica-set example.
There was a problem hiding this comment.
🟡 Changes recommended
Recovery instructions and sharded chunk-distribution behavior conflict with existing documentation.
Get a fresh assessment by requesting another Copilot review.
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 2
- Review effort level: Balanced
|
|
||
|
|
||
| !!! note | ||
| For a ranged shard key, PCSM recreates the source chunk boundaries on the target before the clone. Later sharding metadata changes are not replicated, so the layouts diverge as each balancer works. That is expected. See [Chunk distribution](sharding.md#chunk-distribution). |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>
Co-authored-by: rasika-chivate <95711051+rasika-chivate@users.noreply.github.com>
| Each PCSM instance has: | ||
|
|
||
| - The same source cluster | ||
| - Its own target cluster |
There was a problem hiding this comment.
"Its own target cluster" is a hard requirement, worth saying why. The lease and the checkpoint on the target are single fixed documents and --group-name doesn't isolate them. That means two instances sharing a target form an HA pair instead of two filtered jobs. One of them assumes STANDBY role and can take over the other's run on failover.
We might want to call that out here and point to the HA page?
No description provided.