[SERVER-60083] ImportCollection should not allow an import to succeed if it is invalid, or can cause problems Created: 20/Sep/21  Updated: 06/Feb/24

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Peter Vertenten Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: storex-shortlist
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Participants:

 Description   

Currently importCollection can import a collection from one mongod version to another that does not support the imported data. This can either lead to a scenario where we could crash the mtm or we think the import succeeded; but in reality the import has put the system in an inconsistent state.

Looking for some safeguards to help avoid scenarios that could get us in trouble.

Also impacts some of the importCollection metadata changes with multi-tenancy.



 Comments   
Comment by Gregory Wlodarek [ 05/Dec/22 ]

Thanks for the clarification, we can implement the above suggestion as a safeguard.

Comment by Peter Vertenten [ 05/Dec/22 ]

gregory.wlodarek@mongodb.com. We are not trying to do that, but worry it may happen accidentally in the future. We were just looking for the mentioned safeguard to make that contract explicit. Today importCollection happens on a live system with many disparate processes may be running, perhaps a process is upgrading a binary concurrently with the import for example.

Comment by Gregory Wlodarek [ 05/Dec/22 ]

peter.vertenten@mongodb.com to clarify, are you running exportCollection on one major version and importCollection on another major version? If so, that's not supported just like with hot backups. You would need to import the collection on the same version it was exported from. What we can do, as milkie@mongodb.com suggested is to include the binary/FCV version in the exportCollection output, so that importCollection will fail if it's run against a different binary/FCV version.

Comment by Brian Lane [ 01/Oct/21 ]

Based on the recent comment from milkie. I will pass this over to execution to review.

Comment by Eric Milkie [ 24/Sep/21 ]

I was actually expecting this to be implemented in MongoDB, above the storage API, since we would want to ensure FCV compatibility in addition to "storage engine data version". That is, the exportCollection command would include in its metadata the binary version and FCV version, and the importCollection command would verify that metadata is right.

Generated at Thu Feb 08 05:48:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.