-
Notifications
You must be signed in to change notification settings - Fork 2
PCSM-148 Sharding support #17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds sharding support to {{pcsm.full_name}} (version 0.7.0) as a technical preview feature. The changes enable replication between sharded MongoDB clusters while maintaining the existing replica set functionality.
Key changes:
- Introduces comprehensive sharding documentation explaining how {{pcsm.short}} connects through
mongosinstances - Updates product documentation to reflect that sharded clusters are now supported (tech preview)
- Restructures workflow documentation to accommodate both replica set and sharded cluster topologies
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| docs/sharding.md | New comprehensive documentation detailing sharding support, prerequisites, connection strings, balancer behavior, and usage instructions |
| docs/limitations.md | Removed "sharded clusters not supported" limitation and added new sharding-specific limitation about chunk distribution |
| docs/intro.md | Restructured workflow documentation with tabs separating replica set and sharded cluster scenarios |
| docs/install/usage.md | Updated references from {{plm}} to {{pcsm}} and clarified workflow steps |
| docs/install/authentication.md | Added sharded cluster connection string examples with mongos configuration |
| docs/deployment.md | Reorganized content with new sections for version requirements, architectures, and deployment types |
Comments suppressed due to low confidence (1)
docs/sharding.md:1
- The link reference points to
sharding.md#limitations, but the sharding.md file does not contain a section with the anchor#limitations. This will result in a broken link. Consider either adding a 'Limitations' section to sharding.md or updating the link to point to the correct section (e.g.,sharding.md#chunk-distribution).
# Sharding support in {{pcsm.full_name}} (Technical Preview)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
cabd0c9 to
0f2c8f6
Compare
47d3e16 to
ccfcc3c
Compare
Added info about results of not replicated metadata
ccfcc3c to
a8bd87b
Compare
|
|
||
| During the replication stage, {{pcsm.short}} copies indexes from the source to the target cluster as follows: | ||
|
|
||
| * **Unique indexes handling**: Unique indexes are copied as non-unique indexes during replication. This allows {{pcsm.short}} to handle potential duplicate data that may exist during the migration process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If index section was added, then please add also
- TTL indexes
- hidden indexes
Those also are "modified" on finalize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor thing. Since in Finalization stage we describe handling of these indexes each with its own point. Maybe we should do the same here instead of bundiling **Unique indexes handling** together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I'm not following. We have "Unique index handling" in the replication stage and "Unique index conversion" in the finalization stage. Then each index type is also described under its dedicated bullet point. What am I missing?
6ce38ae to
5c7feb9
Compare
docs/intro.md
Outdated
|
|
||
| 3. **Real-time replication**: After the initial data sync, {{pcsm.short}} monitors changes in the source and replicates them to the target at runtime. You don't have to stop your source deployment—it operates as usual, accepting client requests. {{pcsm.short}} uses [change streams :octicons-link-external-16:](https://www.mongodb.com/docs/manual/changeStreams/) to track the changes to your data and replicate them to the target. | ||
|
|
||
| 4. **Control replication**: You can `pause` the replication and `resume` it later. When paused, {{pcsm.short}} saves the timestamp when it stops the replication. After you resume {{pcsm.short}}, it copies the changes from the saved timestamp and continues real-time replication. See [Pause the replication](install/usage.md#pause-the-replication) and [Resume the replication](install/usage.md#resume-the-replication) for command details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it copies the changes from the saved timestamp and continues real-time replication.
It will not copy anything after you resume, but rather PCSM starts watching change stream events from the moment the pause happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
|
|
||
| * **Index creation during sync**: If an index is created on the source cluster while the clusters are in sync, {{pcsm.short}} automatically creates the same index on the target cluster. | ||
|
|
||
| * **Failed index creation**: If {{pcsm.short}} cannot create an index during replication, it proceeds with replication and records the failure. The index creation will be retried during the finalization stage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add here the same for incomplete indexes. If the index build is in progress, PCSM will record that in the catalog and proceed with clone. In finalization PCSM will try to create them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
|
|
||
| During the replication stage, {{pcsm.short}} copies indexes from the source to the target cluster as follows: | ||
|
|
||
| * **Unique indexes handling**: Unique indexes are copied as non-unique indexes during replication. This allows {{pcsm.short}} to handle potential duplicate data that may exist during the migration process. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a minor thing. Since in Finalization stage we describe handling of these indexes each with its own point. Maybe we should do the same here instead of bundiling **Unique indexes handling** together.
0d8db1b to
8e79166
Compare
8e79166 to
4843e73
Compare
No description provided.