Details
-
Task
-
Resolution: Fixed
-
Major - P3
-
None
-
Fully Compatible
-
Sharding 2017-09-11, Sharding 2017-10-02
Description
We should extend the work from SERVER-30681 to use a readPreference of "secondary" in order to gain testing coverage of the "Secondaries chunk aware" project. When {sharding: {enabled: true}} is used as the cluster options, then the collections prepared by the concurrency framework are automatically sharded (typically using an {_id: "hashed"} shard key).
|
worker_thread.js |
if (args.sessionOptions !== undefined) { |
// Start session |
myDB = ...
|
|
|
if (args.sessionOptions.causallyConsistentReads) { |
// TODO SERVER-30679: We manually enable causal consistency on the connection object so that |
// "afterClusterTime" is injected into the readConcern of any command requests through this |
// connection. |
myDB.getMongo().setCausalConsistency();
|
myDB.getMongo().setReadPref("secondary"); |
}
|
}
|
Note: FSM workloads that use a unique collection or database name in order to avoid highly-destructive actions for other FSM workloads won't use a sharded collection. Additionally, FSM workloads that drop the collection or database as part of their state functions won't re-create the collection as a sharded collection. We should try experimenting with implicitly_shard_accessed_collections.js override to automatically create (or re-create) the collection as a sharded collection in these cases. It's possible that similar to the sharded_collections_jscore_passthrough.yml test suite, some FSM workloads may have internal assertions or invariants that get violated if a collection was known to have been dropped by an FSM worker thread comes back on its own.
Attachments
Issue Links
- depends on
-
SERVER-30681 Run the concurrency suite with causal consistency enabled
-
- Closed
-
- related to
-
SERVER-31456 Concurrency framework doesn't enforce causal relationship between main thread and worker threads
-
- Closed
-