[SERVER-34651] Performance regression on secondary application with retryable batched writes Created: 24/Apr/18  Updated: 29/Oct/23  Resolved: 07/May/18

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.6.4, 3.7.4
Fix Version/s: 3.6.5, 4.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Randolph Tan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-40898 Transaction table updates may be appl... Closed
is related to SERVER-32445 config.transactions table can get out... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6
Sprint: Sharding 2018-05-07, Sharding 2018-05-21
Participants:
Linked BF Score: 28

 Description   

SERVER-32445 made it such that every write that has txnId will introduce an extra write on the config.transactions in the secondary.



 Comments   
Comment by Githook User [ 07/May/18 ]

Author:

{'email': 'randolph@10gen.com', 'name': 'Randolph Tan', 'username': 'renctan'}

Message: SERVER-34651 Squash writes for updates to config.transactions during secondary replication

(cherry picked from commit 9ad3e80ab007d0a97b1607e0717df347e950b4d0)
Branch: v3.6
https://github.com/mongodb/mongo/commit/d0a80a3d209817aa810e6e35429e729c30be7b54

Comment by Githook User [ 07/May/18 ]

Author:

{'email': 'randolph@10gen.com', 'name': 'Randolph Tan', 'username': 'renctan'}

Message: SERVER-34651 Squash writes for updates to config.transactions during secondary replication
Branch: master
https://github.com/mongodb/mongo/commit/9ad3e80ab007d0a97b1607e0717df347e950b4d0

Comment by Spencer Brody (Inactive) [ 27/Apr/18 ]

lgtm

Comment by Benety Goh [ 26/Apr/18 ]

Seems reasonable to me.

Comment by Kaloian Manassiev [ 24/Apr/18 ]

With the goal of making retryable writes enabled by default it will become more important that there is no noticeable performance impact and given that direct writes to the transactions table are very rare, this approach sounds good to me.

Comment by Randolph Tan [ 24/Apr/18 ]

One proposal is to do a similar thing before the SERVER-32445 change where updates to config.transactions are buffered and squashed to one write per lsid. The "buffered" updates to config.transactions will need to be "flushed" (convert to oplog entry with writes to config.transactions) whenever an oplog entry with direct write to config.transactions is encountered and at the end of an oplog batch.

What do you think? benety.goh, spencer & kaloian.manassiev

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