-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: dbCheck
-
Replication
-
Fully Compatible
-
v8.0, v7.0, v6.0
-
Repl 2024-07-22, Repl 2024-08-05, Repl 2024-08-19
To enable:
- jstests/core/administrative/current_op/currentop.js - jstests/core/fsync.js
- Investigate why the dbcheck is running many threads and eating up all WT tickets and fix that:
( theory: that might be caused by starting a new dbcheck while the old one is still not finished so me may wait for: (SERVER-79918Add ns and uuid to dbCheck start/stop health log entries) that is more consistent.)
# When a transaction is in a prepared state, as seen in that test, it prevents the document edited # within it from being read by the dbcheck process. Therefore, if the test keeps the transaction # in a prepared state for an extended period, it will result in a timeout for the dbcheck process. - jstests/core/txns/prepare_conflict.js
- I think we can get around that by increasing the time limit of dbcheck.
# This test adds an invalid view, resulting in a failure of the 'listCollections' operation with # an 'InvalidViewDefinition' error. - jstests/core/views/invalid_system_views.js
- we can get around it by ignoring its database upon a failure of the ‘listCollections’.
# The DBCheck process continuously populates the currentOp, causing this test to time out while # waiting for empty 'getMore' requests. - jstests/core/query/awaitdata_getmore_cmd.js
- can we filter out the dbCheck command from currentOp.
- depends on
-
-
- Backlog
-
- related to
-
-
- Closed
-