[SERVER-29452] Handle missing featureCompatibilityVersion document during startup Created: 06/Jun/17  Updated: 30/Oct/23  Resolved: 17/Oct/17

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Maria van Keulen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-31254 Fail initial sync if fCV targetVersio... Closed
is depended on by SERVER-29453 Disallow removing the featureCompatib... Closed
Related
related to SERVER-32909 Update --repair to restore a missing ... Closed
related to SERVER-35136 Remove featureCompatibilityVersion do... Closed
is related to SERVER-40009 Set/honour initial sync flag at the e... Closed
is related to SERVER-29350 Bump featureCompatibilityVersion to 3.6 Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-08-21, Storage 2017-09-11, Storage 2017-10-02, Storage 2017-10-23
Participants:

 Description   

The proposed implementation for this ticket follows:

Startup behavior without --repair

Fail to start up. If some/all collections have UUIDs set, advise to repair. If no collections have UUIDs, advise to first upgrade to 3.4

Startup behavior with --repair

If there are no collections with UUIDs, advise users to first upgrade to 3.4 and fail. This would occur when the featureCompatibilityVersion document is missing for 3.4 users who have not begun upgrading to 3.6 and 3.2 users.

If no admin.system.version collection exists, create one without UUID.

If only some collections have UUIDs, upsert the following document into admin.system.version:

{ featureCompatibilityVersion: "3.4", targetVersion: "3.6" }

This would occur if we were running featureCompatibilityVersion 3.6 but accidentally deleted either the admin.system.version collection or the admin database, or if we were in the middle of a 3.4 to 3.6 schema upgrade and deleted the featureCompatibilityVersion document.

If all collections have UUIDs, including admin.system.version, upsert the following document into admin.system.version:

{ featureCompatibilityVersion: "3.6" }

We interpret the database as being fully upgraded to featureCompatibilityVersion 3.6, and we insert a featureCompatibilityVersion 3.6 document into the admin.system.version collection. This case would only occur if we were running featureCompatibilityVersion 3.6 and the featureCompatibilityVersion document were accidentally removed or corrupted.



 Comments   
Comment by Githook User [ 20/Oct/17 ]

Author:

{'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}

Message: SERVER-29452 Correctly obtain the UUID of a collection in setfcv test
Branch: master
https://github.com/mongodb/mongo/commit/e739ab399cc3072158e90141334ac00957c07e6f

Comment by Githook User [ 17/Oct/17 ]

Author:

{'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}

Message: SERVER-29452 Reduce the size of dur_checksum journal files
Branch: master
https://github.com/mongodb/mongo/commit/eda6220cbf62a679c2db6a9bc925d3187f0a9b0f

Comment by Maria van Keulen [ 17/Oct/17 ]

Fix to reduce the size of the dur_checksum journal files:
https://github.com/mongodb/mongo/commit/eda6220cbf62a679c2db6a9bc925d3187f0a9b0f

Comment by Githook User [ 16/Oct/17 ]

Author:

{'email': 'maria@mongodb.com', 'name': 'Maria van Keulen', 'username': 'mvankeulen94'}

Message: SERVER-29452 Handle missing featureCompatibilityVersion document
Branch: master
https://github.com/mongodb/mongo/commit/c9ca12d30bbfff9abc1717f2460b8a54f965bf89

Comment by Ian Whalen (Inactive) [ 09/Oct/17 ]

Bumping to GA required based on 9/29 convo with Eric and 10/9 convo with Spencer.

Comment by Maria van Keulen [ 29/Sep/17 ]

The work for refusing to initial sync from nodes reporting fcv < 3.4 will now be done in SERVER-31254.

Comment by Maria van Keulen [ 26/Sep/17 ]

tess.avitabile The targetVersion field will be added as part of SERVER-31209 because sharding needs a durable representation of whether there is an upgrade or downgrade in progress.

Comment by Tess Avitabile (Inactive) [ 26/Sep/17 ]

When do we use the targetVersion field?

Comment by Tess Avitabile (Inactive) [ 11/Aug/17 ]

That would work.

Comment by Andy Schwerin [ 11/Aug/17 ]

Maybe we should just refuse to initial sync from nodes reporting fcv < 3.4?

Comment by Tess Avitabile (Inactive) [ 11/Aug/17 ]

We should also cover the case where you start a fresh 3.6 node and initial sync and do not receive a featureCompatibilityVersion document. The 3.6 node should also fassert in this case.

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