Loading...

XML

Word

Printable

JSON

Type: Improvement
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 3.4.9, 3.5.12
Affects Version/s: None
Component/s: Replication
Labels:
- todo_in_code

Backwards Compatibility:
Fully Compatible
Backport Completed:

3.4.8
Sprint:
Repl 2017-07-31, Repl 2017-08-21

The applyOps command currently takes out a global exclusive lock and applies operations serially. This limits the number of operations that can be applied due to the lack of concurrency. Having applyOps (when in non-atomic mode) not take out a global lock would allow us to parallelize applyOps calls and take advantage of collection- and document-level locking.

is related to

SERVER-23326 applyOps should use a single WriteUnitOfWork where possible

Closed

SERVER-28594 non-atomic applyOps should log each individual op

Closed

SERVER-29874 Two Phase Drops: dropDatabase does not work with applyOps

Closed

SERVER-7452 Add an upsert flag to the applyOps command

Closed

SERVER-23892 Do periodic replicated writes every 10 seconds while idle (for maxStalenessMS)

Closed

SERVER-29224 Move applyOps out of db/catalog/ and into db/repl/oplog

Closed

related to

TOOLS-1886 oplog restore triggers server log warnings about atomic operations with timestamps

Accepted

SERVER-43458 Remove TempRelease in dropDatabase

Closed

SERVER-59750 Clean up todo of TempRelease in dropDatabase

Closed

SERVER-30536 disallow applyOps non-atomic mode when preCondition flag is used

Closed

SERVER-30554 relax locking mode in applyOps when applying CRUD-only ops non-atomically

Closed

(1 is related to, 5 related to)

Assignee:: Benety Goh

Reporter:: Steve Briskin (Inactive)

Participants:: Benety Goh, Githook User, Steve Briskin

Votes:: 0 Vote for this issue

Watchers:: 15 Start watching this issue

Created:: Jun 22 2017 08:38:07 PM UTC

Updated:: Oct 30 2023 11:15:47 PM UTC

Resolved:: Aug 07 2017 05:36:29 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates