Skip to content

Conversation

@nastena1606
Copy link
Collaborator

No description provided.

Copy link

Copilot AI left a 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 mongos instances
  • 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.

Added info about results of not replicated metadata

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.
Copy link
Contributor

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

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.
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.
Copy link
Collaborator

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.

@nastena1606 nastena1606 force-pushed the PCSM-148-Sharding-support branch from 0d8db1b to 8e79166 Compare December 23, 2025 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants