-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
v4.2
-
Repl 2019-06-17
The goal is to allow building OplogEntry progressively and pass OplogEntry into logOp(), which has 13 arguments right now, and the functions under it. This ticket is a prerequisite of that work.
Building oplog entry with 16 arguments is cumbersome and hard to read. We've seen people define various makeOplogEntry() helpers, especially in tests, to ease it. The ticket will help on that too.
In SERVER-31356, we made OplogEntry immutable because the comparison compares raw. We also used to use BSONObj everywhere to reference an oplog entry. Besides, OplogEntry isn't referenced as const, so it's safer to make them immutable.
As of now, I think it's possible to make OplogEntry mutable again.
The comparison of OplogEntry is only called by dasserts and in tests. It's fine to replace them with a slower version or invariant raw is set.
After benety.goh's applier refactoring, OplogEntry replaces BSONObj in the whole oplog application process after popping from the oplog buffer (SyncTail::tryPopAndWaitForMore). The raw field is only used at where we write down the original oplog entry on secondary, which makes sense for performance reasons. We could make raw private as this comment says, expose a getter and add an invariant to ensure it's set.
We'll need to audit the types in secondary oplog application to make sure OplogEntry is referenced as const everywhere. Another idea is to rename OplogEntry to MutableOplogEntry and make OplogEntry as const MutableOplogEntry. Private inheritance or explicitly delete the inherited methods in a subclass are other ideas.
- is related to
-
SERVER-37180 Use OplogEntry everywhere in oplog application
- Closed
- related to
-
SERVER-31356 make OplogEntry immutable
- Closed
-
SERVER-35353 Use OplogEntry class in logOp
- Closed