[SERVER-31686] Add an easy way to take action on no-op oplog entries Created: 23/Oct/17 Updated: 06/Dec/22 Resolved: 19/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | 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 | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
We've started using no-op oplog entries as ways to convey internal information throughout the system - for example in change streams and as part of retriable writes. This usage is likely to increase with future transaction work. No-op oplog entries, however, do not currently have an OpObserver. We should add an easy way for secondaries (and maybe also primaries?) to listen for and take action on any no-op oplog entries, potentially by working them into the existing OpObserver system or potentially via a new mechanism |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 19/Apr/18 ] |
|
We'll deal with this if it comes up again. |