[SERVER-30827] Provide new interface for getting new OpTimes for vector insert from the optime generator Created: 25/Aug/17  Updated: 30/Oct/23  Resolved: 22/Apr/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.6.0

Type: Task Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-30639 Timestamp bulk writes Closed
Duplicate
is duplicated by SERVER-40707 Secondary couldn't signal OplogWaiter... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4
Sprint: Storage 2017-09-11
Participants:

 Description   

Currently, the optime generator is only accessed via logOp() and logInsertOps() called via an opObserver.
There is a need for being able to obtain (and reserve) optimes prior to opObservers being run; the work for this ticket will be to thread through an interface for obtaining a new block of OpTimes and providing logInsertOps() with these times.

One such need is for transactions that write multiple oplog entries, such as vectored insert.



 Comments   
Comment by Eric Sedor [ 22/Apr/19 ]

This ticket fixed the issue described in SERVER-40707, but per siyuan.zhou a full backport may not be necessary.

If it is straightforward to backport this fix to 3.4, that would help mitigate write latency spikes on sharded clusters when a Secondary config server is chaining during a blocking cache update, as is observed in SERVER-40065.

Comment by Ramon Fernandez Marina [ 12/Sep/17 ]

Author:

{'username': u'milkie', 'name': u'Eric Milkie', 'email': u'milkie@10gen.com'}

Message:SERVER-30827 SERVER-30639 Timestamp bulk writes via changes to optime generator
Branch:master
https://github.com/mongodb/mongo/commit/6264d36ac6002b296aa41b8dc79400fcc2cbdd74

Comment by Ian Whalen (Inactive) [ 01/Sep/17 ]

Superseded by SERVER-30639.

Comment by Eric Milkie [ 25/Aug/17 ]

Proposal is to reduce the number of parameters to logOp() as part of this work.

Generated at Thu Feb 08 04:25:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.