[DOCS-12096] Primaries journal much more frequently Created: 28/Sep/18  Updated: 29/Oct/23  Resolved: 12/Nov/19

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kelsey Schubert Assignee: Kay Kim (Inactive)
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by DOCS-12298 Discrepancy on journal commit interval Closed
Related
related to DOCS-13207 Mongod Journaling docs are incomplete... Closed
Participants:
Days since reply: 4 years, 13 weeks, 1 day ago
Epic Link: DOCSP-1769

 Description   

Description

https://docs.mongodb.com/manual/core/journaling/#journaling-process currently suggests that we journal every 50 milliseconds. On a primary this does not hold true, as secondaries are only allowed to read writes that have been journaled on the Primary. As a result, its reasonable to expect that the journal constantly be flushed to disk.

cc geert.bosch

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 12/Nov/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency (secondary)
Branch: v3.6
https://github.com/mongodb/docs/commit/f6f579e0f7fc7fa0998e738c4f9d4c3f945c8eeb

Comment by Githook User [ 12/Nov/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency (secondary)
Branch: v4.0
https://github.com/mongodb/docs/commit/7b3f3af433fed06f1de7f2c8e546c135ba85bf41

Comment by Githook User [ 12/Nov/19 ]

Author:

{'username': 'kay-kim', 'email': 'kay.kim@10gen.com', 'name': 'Kay Kim'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency (secondary)
Branch: master
https://github.com/mongodb/docs/commit/bb86dbe5e5b1dbade1108dc288a3ddaa94bc9905

Comment by Githook User [ 12/Nov/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency
Branch: v3.6
https://github.com/mongodb/docs/commit/c609c2cddd1bd221c3b0560ba5895a90a69c1c25

Comment by Githook User [ 12/Nov/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency
Branch: v4.0
https://github.com/mongodb/docs/commit/8fece02cd4b75d532a4f9385f3c4a9654d5c3d9a

Comment by Githook User [ 12/Nov/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-12096,DOCS-13207: clarify journaling frequency
Branch: master
https://github.com/mongodb/docs/commit/a08ebfe5b32f636b0ba60fb7a261c4c5d8b9b3c7

Comment by Eric Milkie [ 13/May/19 ]

Note that the Replicate before Journal project PM-1274 will change this logic.

Comment by Geert Bosch [ 20/Dec/18 ]

When a secondary is actively waiting for new oplog entries (it has an active getMore on a tailable cursor on the oplog collection), it will cause immediate flushes. Since SERVER-35657, which is backported to 4.0 and 3.6, this is also the case if threads are waiting for oplog entries to become visible. As secondaries lag, individual reads return larger amounts of data, so the frequency of oplog flushes will decrease.

The journal frequency is given by the journalCommitInterval server parameter, and defaults to 100ms. However, on replica sets, both the regular journal flushing and the oplog manager's journal flushing happen every 100ms. So you could expect to see journal writes on average at least once every 50ms, even if there are no oplog readers. Now, this is an implementation detail that I hope will go away soon (we want to support secondaries reading the oplog before it has been flushed), so I think it's fine to say every 100ms.

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