[SERVER-35271] 4.0 rc0 upgrade from 3.6.5 logs "unsupported WiredTiger file version" error Created: 29/May/18  Updated: 29/Oct/23  Resolved: 15/Jun/18

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: 4.0.0-rc0
Fix Version/s: 3.6.15, 4.0.0-rc6, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Spencer Brown Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-34630 Change WiredTiger compatibility versi... Closed
Problem/Incident
causes SERVER-45935 [3.6] WT error handler incorrectly pr... Closed
Related
related to WT-4127 Add common prefix for compatibility v... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Steps To Reproduce:

1. Create a standalone MongoDB 3.4.15 instance.
2. Upgrade to MongoDB 3.6.5 by starting new binaries.
3. Set FCV to "3.6".
4. Upgrade to MongoDB 4.0.0 rc0 by starting new binaries.
5. Examine the mongod log file for the unsupported WT file version error.

Sprint: Storage NYC 2018-06-04, Storage NYC 2018-06-18
Participants:
Linked BF Score: 63

 Description   

Created a MongoDB 3.4.15 standalone, then upgraded to 3.6.5, set FCV to "3.6", then upgraded to 4.0.0 rc0. See a message in the log file:

2018-05-29T12:15:43.124-0500 E STORAGE  [initandlisten] WiredTiger error (-31802) [1527614143:124208][2993:0x7fffddf7a3c0], connection: unsupported WiredTiger file version: this build requires a minimum version of 3, and the file is version 2: WT_ERROR: non-specific WiredTiger error

but, things seem to be working.

If WT file version 2 is supported in 4.0, this message should be a warning at most.

Also, how would one go about converting to version 3, if there is a reason to do so?



 Comments   
Comment by Githook User [ 29/Aug/19 ]

Author:

{'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb', 'username': 'dgottlieb'}

Message: SERVER-35271: Suppress WT compatibility error messages on startup.

(cherry picked from commit 34b3da52dc10216453eed6dd0939f7cb4acc546a)
Branch: v3.6
https://github.com/mongodb/mongo/commit/143edc21c045a7c47c10ce4bcf552481789b7117

Comment by Githook User [ 15/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-35271: Suppress WT compatibility error messages on startup.

(cherry picked from commit 34b3da52dc10216453eed6dd0939f7cb4acc546a)
Branch: v4.0
https://github.com/mongodb/mongo/commit/1115621110be9bd82079f425f766e2350ed5208d

Comment by Githook User [ 15/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-35271: Suppress WT compatibility error messages on startup.
Branch: master
https://github.com/mongodb/mongo/commit/34b3da52dc10216453eed6dd0939f7cb4acc546a

Comment by Githook User [ 14/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: Revert "SERVER-35271: Suppress WT compatibility error messages on startup."

This reverts commit 41954217c7c132bb7ad49dff49bdba20681ab36a.
Branch: v4.0
https://github.com/mongodb/mongo/commit/efcf4332fd26af56452807d69d40ca78ccaf072d

Comment by Githook User [ 14/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: Revert "SERVER-35271: Suppress WT compatibility error messages on startup."

This reverts commit ef999ac2018d29fd7425ea32df03eaab37d4709b.
Branch: master
https://github.com/mongodb/mongo/commit/d7db8c9d6f433a462abef8781fdb507681f6b694

Comment by Githook User [ 14/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-35271: Suppress WT compatibility error messages on startup.

(cherry picked from commit ef999ac2018d29fd7425ea32df03eaab37d4709b)
Branch: v4.0
https://github.com/mongodb/mongo/commit/41954217c7c132bb7ad49dff49bdba20681ab36a

Comment by Githook User [ 14/Jun/18 ]

Author:

{'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}

Message: SERVER-35271: Suppress WT compatibility error messages on startup.
Branch: master
https://github.com/mongodb/mongo/commit/ef999ac2018d29fd7425ea32df03eaab37d4709b

Comment by Alexander Gorrod [ 13/Jun/18 ]

My vote here is for WiredTiger to use a common prefix for compatibility related error messages - essentially option 3 above. WiredTiger can promise not to change that prefix. I've opened WT-4127 to track the WiredTiger side of this work.

Comment by Michael Cahill (Inactive) [ 12/Jun/18 ]

I still don't love it – checking for specific strings is fragile – but can live with it for now. Thanks daniel.gottlieb and sue.loverso.

Comment by Daniel Gottlieb (Inactive) [ 08/Jun/18 ]

If michael.cahill is ok with this, I'll move forward with assigning a code reviewer for the patch next week.

Comment by Susan LoVerso [ 08/Jun/18 ]

I'm personally a fan of this, probably not surprisingly. In the WT compatibility code functions just parsing the args and checking there are 10 different error messages for different things plus more in the logging code itself. That compares to you currently checking for two messages. So it would be difficult to filter inside to know what messages should or should not be quieted.

Comment by Michael Cahill (Inactive) [ 01/Jun/18 ]

sue.loverso, the problem with having the event handler filter out messages is that when this wiredtiger_open call succeeds, the event handler remains in place for the whole time the connection is open. So the logic would be something like "skip the first message if it matches 'unsupported WiredTiger.* version'".

If MongoDB passed compatibility=(require_min="3.1",quiet=true) to suppress the error message, would that be terrible?

Comment by Susan LoVerso [ 30/May/18 ]

What is happening is that MongoDB sets a compatibility=(require_min="3.1") and the version of log files is earlier than that version. Looking at the server code, it attempts to open with decreasing release numbers in wiredtiger_kv_engine.cpp. That is how the system appears to keep running after the error message.

michael.cahill I think that WiredTiger is doing the right thing in giving an error message in this case. The caller is explicitly asking for a required minimum that the current database does not meet. That is an error situation.

I think suppressing the message should be done in MongoDB. I think sending in a special event handler to wiredtiger_open that knows it is in this discovery mode and can ignore or otherwise choose to do something with this message would work. Or set a flag so that the existing event handler knows it is in this mode and can eat the message, or rethink the decreasing compatibility algorithm.

Comment by Michael Cahill (Inactive) [ 30/May/18 ]

sueloverso, any thoughts on suppressing the message in this case? It's technically possible for MongoDB to do it via message handling trickery but probably better done inside WT.

Comment by Spencer Brown [ 29/May/18 ]

Yes, if I set the FCV to "4.0" after upgrading to 4.0.0-rc0, upon restarting the mongod, the log message about "unsupported WiredTiger file version" is no longer there.

Comment by Eric Milkie [ 29/May/18 ]

The behavior is as-designed; we should add more explanatory messages to the log in order to assuage any fears that something is going wrong.

(WireTiger file version 1 is FCV 3.4, version 2 is FCV 3.6, and version 3 is FCV 4.0)

Comment by Spencer Brown [ 29/May/18 ]

Note: the same symptom occurs with a fresh instance of MongoDB 3.6.5. To reproduce this problem, it is not necessary to start with MongoDB 3.4.15 and upgrade to 3.6.5.

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