[SERVER-61876] Mongo has been in the recovery state after restarting Created: 03/Dec/21  Updated: 08/Mar/22  Resolved: 08/Mar/22

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

Type: Bug Priority: Major - P3
Reporter: 帆 张 Assignee: Eric Sedor
Resolution: Done Votes: 0
Labels: recovering
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive mongo-debug.zip    
Issue Links:
Duplicate
is duplicated by SERVER-61875 Mongo has been in the recovery state ... Closed
Operating System: ALL
Steps To Reproduce:

restart it

Participants:

 Description   

I have a replica set cluster with 1 member, and when I restart it, it has been in the recovering state。Before I restarted, it was in the primary state。

I intercepted its startup log, hoping to help diagnose the problem。

This confuses me

test-gxm-fa842-replica0:RECOVERING> rs.status()test-gxm-fa842-replica0:RECOVERING> rs.status(){ "set" : "test-gxm-fa842-replica0", "date" : ISODate("2021-12-03T08:22:58.647Z"), "myState" : 3, "term" : NumberLong(10), "syncSourceHost" : "", "syncSourceId" : -1, "heartbeatIntervalMillis" : NumberLong(2000), "majorityVoteCount" : 1, "writeMajorityCount" : 1, "votingMembersCount" : 1, "writableVotingMembersCount" : 1, "optimes" : { "lastCommittedOpTime" : { "ts" : Timestamp(0, 0), "t" : NumberLong(-1) }, "lastCommittedWallTime" : ISODate("1970-01-01T00:00:00Z"), "appliedOpTime" : { "ts" : Timestamp(1638519598, 1), "t" : NumberLong(1) }, "durableOpTime" : { "ts" : Timestamp(1638519598, 1), "t" : NumberLong(1) }, "lastAppliedWallTime" : ISODate("2021-12-03T08:19:58.388Z"), "lastDurableWallTime" : ISODate("2021-12-03T08:19:58.388Z") }, "lastStableRecoveryTimestamp" : Timestamp(1638519548, 1), "members" : [ { "_id" : 0, "name" : "test-gxm-fa842-replica0-0-0.test-gxm-fa842-replica0-headless.qfusion-admin:27017", "health" : 1, "state" : 3, "stateStr" : "RECOVERING", "uptime" : 42, "optime" : { "ts" : Timestamp(1638519598, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2021-12-03T08:19:58Z"), "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "Could not find member to sync from", "configVersion" : 1, "configTerm" : 1, "self" : true, "lastHeartbeatMessage" : "" } ], "ok" : 1}



 Comments   
Comment by Eric Sedor [ 08/Mar/22 ]

Hi,

We haven’t heard back from you for some time, so I’m going to close this ticket. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Regards,
Eric

Comment by Eric Sedor [ 31/Jan/22 ]

justonezf@gmail.com, are you able to provide mongod.log files and the $dbpath/diagnostic.data directory for this incident, or a recent occurrence of a similar incident?

Comment by Eric Sedor [ 10/Dec/21 ]

Hi justonezf@gmail.com and sorry for the delay,

Can you confirm the restart in question was at 2021-12-03T08:22:16.678+00:00?

Could you please also archive (tar or zip) the mongod.log file immediately prior to the restart, and the $dbpath/diagnostic.data directory (the contents are described here) and upload them to this support uploader location?

Files uploaded to this portal are visible only to MongoDB employees and are routinely deleted after some time.

Gratefully,
Eric

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