[SERVER-38354] Allow shutdown error when reading last applied optime on startup Created: 30/Nov/18  Updated: 29/Oct/23  Resolved: 20/Dec/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.0.7, 4.1.7

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

Issue Links:
Backports
Depends
Related
related to SERVER-27534 All writing operations must fail if t... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Repl 2018-12-17, Repl 2019-01-14
Participants:
Linked BF Score: 58

 Description   

Shutdown errors should be acceptable in  BackgroundSync::_readLastAppliedOpTimeWithHash().



 Comments   
Comment by Githook User [ 22/Feb/19 ]

Author:

{'name': 'Siyuan Zhou', 'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com'}

Message: SERVER-38354 Allow shutdown error in reading last applied optime on startup

(cherry picked from commit 9301f8067521d2e7178b698cc521eab990187aee)

SERVER-38354 remove unused variable

(cherry picked from commit 47d5c44e53cb8414ba18564a21ca445579d86875)
Branch: v4.0
https://github.com/mongodb/mongo/commit/171c259a11e206a082fd92c3afbba8a7c7af8342

Comment by Githook User [ 20/Dec/18 ]

Author:

{'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}

Message: SERVER-38354 remove unused variable
Branch: master
https://github.com/mongodb/mongo/commit/47d5c44e53cb8414ba18564a21ca445579d86875

Comment by Githook User [ 20/Dec/18 ]

Author:

{'username': 'visualzhou', 'email': 'siyuan.zhou@mongodb.com', 'name': 'Siyuan Zhou'}

Message: SERVER-38354 Allow shutdown error in reading last applied optime on startup
Branch: master
https://github.com/mongodb/mongo/commit/9301f8067521d2e7178b698cc521eab990187aee

Comment by Tess Avitabile (Inactive) [ 03/Dec/18 ]

Got it, thanks for looking into this.

Comment by Siyuan Zhou [ 03/Dec/18 ]

tess.avitabile, I think you're right that we don't have to backport to 3.6 since the fix of SERVER-27534 is on 3.6 is different from 4.0.

Note that in our master branch, we committed a more ambitious fix for
this, which modifies lock acquisitions to always check for interrupt
(obviating the need for the interrupt checks in these batch modify
functions). That will hopefully prevent future problems like this.

On the 3.6 branch, though, we just fix the case described in the Jira
ticket by moving interrupt checks to happen after we take a collection
lock (which helps because a stepdown can't occur while the lock is
held).

Comment by Siyuan Zhou [ 01/Dec/18 ]

I believe shutdown becomes possible because we check for interruptions when acquiring locks in SERVER-27534, so we need to backport up to 3.6 if we want to.

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