[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. |