-
Type:
Improvement
-
Resolution: Won't Fix
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
Replication
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In steady-state replication we call OplogApplier::startup (from ReplicationCoordinatorExternalStateImpl::startSteadyStateReplication) and make the OplogApplier responsible for running the oplog application loop on a thread, until ReplicationCoordinatorExternalStateImpl calls OplogApplier::shutdown.
In initial sync, rollback, and recovery, however, external classes each create an OplogApplier but do not call its startup method. Instead, these external classes drive the oplog application process.
Let's consider ways to make steady-state replication more consistent with other OplogApplier users. Perhaps there is a new class named like "SteadyStateSyncer" that is a peer of InitialSyncer and BackgroundSync. Like those two classes, the SteadyStateSyncer creates an OplogApplier and drives the oplog application process. We'll delete OplogApplier::startup/shutdown, and move the logic from OplogApplierImpl::_run into SteadyStateSyncer.