[SERVER-41882] Finish the OplogApplier Created: 24/Jun/19 Updated: 02/Oct/19 Resolved: 02/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Mihai Andrei |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2019-09-23, Repl 2019-10-07 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Description |
|
Currently oplog application is split between OplogApplier, SyncTail, applyOps, transaction_oplog_application.cpp, and oplog.cpp. The OplogApplier is the direction we want to be moving towards but it wasn't fully completed. We likely will not want to merge everything together, but we will save ourselves a lot of time in the future if we finish the OplogApplier and make oplog application code much more straightforward. From the epic's design doc, this is the step "Merge SyncTail into OplogApplierImpl": These two classes are tightly coupled, and don't have a clear separation of concerns. It appears we intended to replace SyncTail with OplogApplierImpl but stopped halfway; let's complete that process. Both classes:
OplogApplierImpl has some distinct responsibilities:
SyncTail has distinct responsibilities:
We will merge SyncTail's methods into OplogApplierImpl incrementally, starting from the root of the call tree:
As a side effect we'll remove the inconsistent "sync" method-naming convention. We'll have the opportunity to review each method's code as we go, improving and updating it. |