[SERVER-29428] Make 3.4 mongod fail gracefully in featureCompatibilityVersion 3.6 cluster Created: 02/Jun/17  Updated: 10/Jan/18  Resolved: 21/Sep/17

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Louis Williams
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-29350 Bump featureCompatibilityVersion to 3.6 Closed
Related
related to SERVER-26264 Make 3.2 mongos fail gracefully on st... Closed
related to SERVER-32633 Provide a framework to ensure a last-... Closed
related to SERVER-31094 Mongos should fail gracefully when po... Closed
is related to SERVER-30920 Starting MongoDB 3.4 where previously... Closed
Sprint: Storage 2017-10-02
Participants:
Linked BF Score: 0

 Description   

In SERVER-29350, we modify mongod to return supported wire versions (6,6) when receiving an isMaster command from an internalClient when the featureCompatibilityVersion is 3.6.

As a result, when starting a new replica set with a 3.6 primary and a 3.4 secondary, the secondary spins, logging:

remote host has incompatible wire version: IncompatibleServerVersion: Server
min and max wire version are incompatible (6,6) with client min wire version
(0,5)

Instead, the processes should quickly exit with a non-zero exit code and a useful error message. The error message should display a "MustUpgrade" error code and should link to the documentation for the 3.4=>3.6 upgrade process.



 Comments   
Comment by Louis Williams [ 21/Sep/17 ]

Due to undesirable behavior seen in v3.4 which causes a new mongos to crash when talking to an old mongod (see BF-6618), this change has been reverted in both v3.4 and master.

Comment by Githook User [ 21/Sep/17 ]

Author:

{'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}

Message: Revert "SERVER-29428 Fail gracefully in mongod when featureCompatibilityVersion is incompatibile"

This reverts commit b35c6fc183c26bc8a6d7cdfc8f5b970f90d60b56.
Branch: master
https://github.com/mongodb/mongo/commit/4725cefbcb398f59a756f13f8d86130e9ee25965

Comment by Githook User [ 20/Sep/17 ]

Author:

{'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}

Message: Revert "SERVER-29428 Fail gracefully in mongod when featureCompatibilityVersions mismatch"

This reverts commit 74cc6a5019576d4bd1c8c2df30b54c4eacc4d484.
Branch: v3.4
https://github.com/mongodb/mongo/commit/9ee11482329e0f2f98853b6e8f105fd8660313a3

Comment by Githook User [ 19/Sep/17 ]

Author:

{'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}

Message: SERVER-29428 Have mongod fail gracefully when featureCompatibilityVersion is of a higher version

(cherry picked from commit b35c6fc183c26bc8a6d7cdfc8f5b970f90d60b56)
Branch: v3.4
https://github.com/mongodb/mongo/commit/d78666cf8dd33359b4e536e160409ebcbeb2fd24

Comment by Githook User [ 19/Sep/17 ]

Author:

{'username': 'louiswilliams', 'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com'}

Message: SERVER-29428 Fail gracefully in mongod when featureCompatibilityVersion is incompatibile
Branch: master
https://github.com/mongodb/mongo/commit/b35c6fc183c26bc8a6d7cdfc8f5b970f90d60b56

Comment by Louis Williams [ 14/Sep/17 ]

For mongos, checking the reason for connection failure is not possible without a refactor of the network connection code. I have opened SERVER-31094 separately for this issue.

Comment by Daniel Gottlieb (Inactive) [ 01/Sep/17 ]

Another symptom that can be confusing for users, is that a 3.4 binary using MMAP on startup will fail and leave a nasty backtrace. See SERVER-30920

Comment by Tess Avitabile (Inactive) [ 22/Jun/17 ]

This also occurs when there is a 3.4 secondary and you set featureCompatibilityVersion=3.6 on the 3.6 primary. If the 3.4 secondary was not needed as part of the majority, the primary may close the connection before it receives the change to the featureCompatibilityVersion document. Then the secondary will just spin, outputting that error message.

Comment by Andy Schwerin [ 02/Jun/17 ]

Great; I was hoping you'd say that.

Comment by Tess Avitabile (Inactive) [ 02/Jun/17 ]

Ah, I see, yes this ticket should also cover making the same change to master.

Comment by Tess Avitabile (Inactive) [ 02/Jun/17 ]

Yes, it should be whenever it has an IncompatibleServerVersion error under those conditions.

Comment by Andy Schwerin [ 02/Jun/17 ]

Will this work also cover the changes to master so that when we do 3.6->3.8 upgrade, 3.6 nodes also fail gracefully when the featureCompatibilityVersion reaches 3.8?

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