[SERVER-56349] Secondaries apply in-place updates to large documents slower than primaries Created: 26/Apr/21  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: WT_MODIFY
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

In-place updates to large documents can be slower on secondaries than primaries, which will result in secondary lag.

This only affects "in-place" updates that change a field's value, but not the document's size.

This is because writers on the primary may generate WT_MODIFY structures (called "damages" by MongoDB) in parallel update stages, and the algorithm does not depend on document size. When these updates are replicated, however, the secondary has to reconstitute the new document and compute a binary diff of the document to generate the WT_MODIFY structures. This can be slower than the operation on the primary, and it scales with the size of the document.

We do not replicate enough information for the secondary to generate WT_MODIFY structures without having to compute a binary diff of the document. We should consider improvements to doc_diff (i.e. used to efficiently replicate updates) that allow it to create WT_MODIFY updates directly.


Generated at Thu Feb 08 05:39:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.