[SERVER-33866] Decouple oplog fetching from oplog application Created: 13/Mar/18 Updated: 22/Aug/23 Resolved: 22/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently we don't fetch a new batch of oplog entries until we have finished applying the previous batch. Instead, we should fetch oplog entries as fast as we can get them from our sync source and write them down, and in parallel we should be applying oplog entries as fast as we can. This would be especially useful in conjunction with |
| Comments |
| Comment by Eric Milkie [ 14/Mar/18 ] |
|
Oplog fetching is already decoupled from oplog application. I think what you mean instead is that the act of writing the oplog is currently coupled to the applier applying batches of oplog entries. This behavior used to be necessary when the "end of the oplog" was meaningful, but we have since changed the logic such that the last batch boundary is durably and separately tracked. Thus, we can certainly write oplog entries into the oplog without regard to the progress of the applier. |