[SERVER-30561] Make migration fail if source is fcv v3.6 and destination is v3.4 Created: 08/Aug/17 Updated: 27/Oct/23 Resolved: 20/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.5.11 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Sharding 2017-11-13 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
This is because v3.4 shards does not know how to receive the session state from the source shard. |
| Comments |
| Comment by Andy Schwerin [ 20/Oct/17 ] |
|
If both binaries are 3.6, then session information will be transferred. If the recipient is binary version 3.4, the migration will fail when the donor notices that the recipient never asked for session information. |
| Comment by Randolph Tan [ 19/Oct/17 ] |
|
This might become unnecessary once |
| Comment by Dianna Hohensee (Inactive) [ 21/Sep/17 ] |
|
Talked offline with renctan about what specifically needs protection. Conclusion is that fcv34 donor -> fcv36 recipient will fail because recipient will fail to acquire session information from the donor, which won't have it prepared in fcv34. For a fcv36 donor -> a fcv34 recipient, the donor can do a check to ensure that its prepared session information was drained by the recipient – a fcv34 recipient won't know to drain the session info from the donor. This check will be included with new actions ( So both mixed version scenarios are going to be covered. This ticket will remain to add the nicety of checking fcv is 3.6 for both shards before starting a migration – so all the data isn't migrated before we abort the migration. I will also include a test to make sure migrations between mixed fcv shards fail. A feature compatibility check should be considered on the new donor shard commands around sessions, say a fcv 3.6 check before the donor services the command request – if this isn't already done by |
| Comment by Randolph Tan [ 16/Aug/17 ] |
|
schwerin found that having a higher fcv will make the lower versions fail to connect to it (code). There might be no extra work needed here other than writing a test to verify this behavior. |
| Comment by Andy Schwerin [ 08/Aug/17 ] |
|
Sounds good to me |
| Comment by Randolph Tan [ 08/Aug/17 ] |
|
schwerin A v3.6 binary mongod can in theory understand how to handle migration of sessions even though it's fcv 3.4 so throwing an error based on FCV is stricter than the binary version. On the other hand, it is easier to implement a correct solution based on FCV, so I think we should check based on FCV. |
| Comment by Andy Schwerin [ 08/Aug/17 ] |
|
This is fcv 3.6/3.4 or binary version 3.6/3.4? I hope the former. |