[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: |
|
||||||||||||||||||||||||||||||||
| Sprint: | Storage 2017-10-02 | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||
| Description |
|
In As a result, when starting a new replica set with a 3.6 primary and a 3.4 secondary, the secondary spins, logging:
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 " This reverts commit b35c6fc183c26bc8a6d7cdfc8f5b970f90d60b56. |
| Comment by Githook User [ 20/Sep/17 ] |
|
Author: {'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}Message: Revert " This reverts commit 74cc6a5019576d4bd1c8c2df30b54c4eacc4d484. |
| Comment by Githook User [ 19/Sep/17 ] |
|
Author: {'email': 'louis.williams@mongodb.com', 'name': 'Louis Williams', 'username': 'louiswilliams'}Message: (cherry picked from commit b35c6fc183c26bc8a6d7cdfc8f5b970f90d60b56) |
| Comment by Githook User [ 19/Sep/17 ] |
|
Author: {'username': 'louiswilliams', 'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com'}Message: |
| 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 |
| 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 |
| 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? |