Conversation
sandraromanchenko
requested review from
chupe and
inelpandzic
as code owners
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a test to verify data consistency after executing the MongoDB movePrimary command, which is used to change the primary shard for an unsharded database. The test ensures that the PCSM (Percona ClusterSync for MongoDB) tool correctly handles and replicates the primary shard changes from source to target clusters.
Key changes:
- Adds a new test file
test_shard_ops.pyfor testing shard-related operations - Implements
test_move_primaryto verify the movePrimary command behavior - Includes error handling for environments where movePrimary is not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
chupe
approved these changes
Dec 31, 2025
chupe
changed the title
The previous approach checked source-side collection existence for both Drop and Create phantom events from movePrimary. This worked for Drop (if the collection still exists on source, the drop is phantom) but was fundamentally broken for Create — collections always exist on source after a real create, so every legitimate create was misidentified as a movePrimary artifact and skipped. Split the detection strategy: Drop events continue checking the source, while Create events now check the in-memory catalog. If the catalog already tracks the collection (meaning PCSM previously cloned or replicated it to the target), the create is phantom and only the UUID is updated. Otherwise it's a real create and proceeds normally.
movePrimary via mongos change stream only emits create events, never drop events. The source-side existence check for drops was incorrectly skipping real collection drops when the collection had been quickly re-created, causing data mismatch in test_csync_PML_T10.
inelpandzic
reviewed
Mar 6, 2026
inelpandzic
approved these changes
Mar 9, 2026
chupe
added a commit
that referenced
this pull request
Mar 23, 2026
On MongoDB 6.0/7.0, movePrimary emits create→drop through the change stream (confirmed empirically). PR #163 handled the phantom create but the subsequent drop was replayed, wiping the target collection. On 8.0 only a phantom create is emitted — no drop follows. Track namespaces where a phantom create was detected in a version-gated map (nil on 8.0+). When a drop arrives for a tracked namespace, skip it instead of replaying on the target.
chupe
added a commit
that referenced
this pull request
Mar 23, 2026
On MongoDB 6.0/7.0, movePrimary emits create then drop through the mongos change stream. PR #163 handled the phantom create but the subsequent drop was replayed, wiping the target collection. Track namespaces where a phantom create was detected. When a drop arrives for a tracked namespace, skip it. Gated on source <8.0 AND sharded topology (IsMongos check) to avoid false positives on RS where create-for-existing-collection is a legitimate recreate, not movePrimary. Also enables sharded E2E tests on 6.0/7.0 in CI (scoped to sharded- specific test files, full suite still blocked by PCSM-255).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PCSM-249
Problem
MongoDB's
movePrimarycommand doesn't emit a dedicated change stream event. Instead, it produces phantomcreateevents for collections that were moved between shards. Without detection, PCSM recreates these collections on the target, resulting in data loss — the target ends up with zero documents for the affected collections.Solution
When handling a Create change event, check the in-memory catalog first. If PCSM already tracks the collection from a prior clone or replicate, the create is phantom — only the UUID is updated via
SetCollectionUUIDto reflect the post-move value. Otherwise it's a real create and proceeds normally.This works because the catalog is an authoritative record of what PCSM has already replicated to the target. A phantom create for a collection the catalog knows about means movePrimary, while a create for an unknown collection means the user actually created it.