[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: |
|
||||||||||||||||||||||||||||
| 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. |
||||||||||||||||||||||||||||
| 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:
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: (cherry picked from commit 34b3da52dc10216453eed6dd0939f7cb4acc546a) |
| Comment by Githook User [ 15/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: (cherry picked from commit 34b3da52dc10216453eed6dd0939f7cb4acc546a) |
| Comment by Githook User [ 15/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: |
| Comment by Githook User [ 14/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: Revert " This reverts commit 41954217c7c132bb7ad49dff49bdba20681ab36a. |
| Comment by Githook User [ 14/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: Revert " This reverts commit ef999ac2018d29fd7425ea32df03eaab37d4709b. |
| Comment by Githook User [ 14/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: (cherry picked from commit ef999ac2018d29fd7425ea32df03eaab37d4709b) |
| Comment by Githook User [ 14/Jun/18 ] |
|
Author: {'username': 'dgottlieb', 'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com'}Message: |
| 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 |
| 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. |