|
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.
|