-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
Restarting an older version of MongoDB on a newer database without following the expected downgrade procedure results in logs that look like this:
2020-04-15T16:35:10.362-0400 E STORAGE [initandlisten] WiredTiger error (-31802) [1586982910:362655][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error Raw: [1586982910:362655][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error 2020-04-15T16:35:10.384-0400 E STORAGE [initandlisten] WiredTiger error (-31802) [1586982910:384912][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error Raw: [1586982910:384912][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error 2020-04-15T16:35:10.400-0400 E STORAGE [initandlisten] WiredTiger error (-31802) [1586982910:400791][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error Raw: [1586982910:400791][25914:0x7f8b6f422a80], connection: __log_open_verify, 985: unsupported WiredTiger file version: this build only supports versions up to 3, and the file is version 5: WT_ERROR: non-specific WiredTiger error
We repeatedly call wiredtiger_open using different require_min and require_max configurations to see whether we can open with a different compatibility version which causes spamming of errors in the log. We partially mitigate this by adding a "Version incompatibility detected:" prefix to certain error messages related to compatibility versions so that MongoDB can silence them in the log.
We should signal somehow in the API whether an error in wiredtiger_open has occurred due to the supplied compatibility version or for some other reason. If it failed for a non-compatibility version related reason, then MongoDB should not follow up with additional calls to wiredtiger_open.
As mentioned before, we're currently doing this in an ad hoc way with the "Version incompatibility detected:" but we should formalize this in our API and commit to keeping it stable so that MongoDB relies on it.
Some ideas include:
- Keeping the prefix string but explicitly document it as part of our API so that MongoDB can string match and only attempt subsequent wiredtiger_open call it the error contains that prefix.
- Return a different error code for this category of error (preferable if possible).
This captures most of the details on what we need to achieve. Look at WT-5998 for some context on the origin of this problem and what we discussed beforehand.
- is related to
-
WT-6015 (4.4-only) Backup test appears to be missing oplog entries
- Closed
-
WT-6324 Need logging to be configured when checking compatibility
- Closed
-
WT-6327 Skip level upgrade.js still failing after applying WT-6324
- Closed
- related to
-
WT-5998 Multiple version incompatible error log strings
- Closed