[SERVER-57689] Update importCollection to support collections that are logically the same, not just binary equivalents Created: 14/Jun/21 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Catalog |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Peter Vertenten | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently importCollection requires every .wt file to be binary equivalents on all nodes. A usage pattern we want to support for backup/restore using direct attach of a disk on each node, and letting recovery run on each node separately, prior to import. This prevents us from having to copy files around over the network. Using this pattern the collections will be logically the same, but the recovery process might have created binary differences in each wt file. If importCollection is run like this currently, we will run into the secondary nodes crashing because they fail the checksum against the export data provided by the primary during the import. |
| Comments |
| Comment by Connie Chen [ 19/Oct/21 ] |
|
michael.gargiulo - If this will be obsolete with Serverless Phase 3, can we close this ticket? |