[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:
Gantt Dependency
has to be done after SERVER-30894 Implement command for retrieving oplo... Closed
Related
is related to SERVER-31631 Bump minimum outgoing wire version fo... Closed
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 SERVER-31631 is implemented.

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 (SERVER-30894).

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 SERVER-30894 as well.

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.

Generated at Thu Feb 08 04:24:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.