|
After some discussion, we realized that this scenario is not important to test. Originally, the thought was to make sure that a EMRC=false node that ends up with a "prepareTransaction" oplog entry can get back to a healthy state by doing a full re-sync. If the rest of the replica set was still engaging in multi-shard transactions, then it may need to sync a prepare/commit oplog entry. It is illegal, however, to be running multi-shard transactions against a replica set that contains a node with EMRC=false (we will document this). If a user wants to re-sync an EMRC=false node that has received a prepare oplog entry that needs to roll back, they need to wait until all previous sharded transactions against that replica set commit or abort, and then do the initial sync. If all of the previous transactions have finished, the EMRC=false node will not need to reconstruct any prepared transactions during its sync or apply any prepare or commit oplog entries. Thus, this scenario is not crucial to test, since with our documented instructions, being able to sync prepare oplog entries when EMRC=false is not necessary to bring such a node back to a healthy state.
Consequently closing this ticket.
|
|
Note that we cannot rely on the passthrough test coverage for prepared transactions because we do not support prepareTransaction in general against nodes with EMRC=false, so those tests won't be able to run by default on the "majority reads off" variant. We can investigate adding a special suite, however, that uses an EMRC=true primary and EMRC=false secondary.
|