[SERVER-26505] Can not start Mongo server Created: 06/Oct/16  Updated: 13/Aug/18  Resolved: 19/Nov/16

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

Type: Bug Priority: Major - P3
Reporter: Harsh C Parikh Assignee: Kelsey Schubert
Resolution: Incomplete Votes: 0
Labels: envns, rns, wtc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Windows
Participants:

 Description   

C:\Program Files\MongoDB\Server\3.2\bin>mongod --dbpath E:\data\Ndata --repair --storageEngine wiredTiger
 
2016-10-06T11:47:44.436-0400 I CONTROL  [main] Hotfix KB2731284 or later update is not installed, will zero-out data files
2016-10-06T11:47:44.439-0400 I CONTROL  [initandlisten] MongoDB starting : pid=7112 port=27017 dbpath=E:\data\Ndata 64-bit host=KND076VC
2016-10-06T11:47:44.440-0400 I CONTROL  [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2016-10-06T11:47:44.441-0400 I CONTROL  [initandlisten] db version v3.2.10
2016-10-06T11:47:44.442-0400 I CONTROL  [initandlisten] git version: 79d9b3ab5ce20f51c272b4411202710a082d0317
2016-10-06T11:47:44.442-0400 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1t-fips  3 May 2016
2016-10-06T11:47:44.443-0400 I CONTROL  [initandlisten] allocator: tcmalloc
2016-10-06T11:47:44.444-0400 I CONTROL  [initandlisten] modules: none
2016-10-06T11:47:44.444-0400 I CONTROL  [initandlisten] build environment:
2016-10-06T11:47:44.444-0400 I CONTROL  [initandlisten]     distmod: 2008plus-ssl
2016-10-06T11:47:44.445-0400 I CONTROL  [initandlisten]     distarch: x86_64
2016-10-06T11:47:44.446-0400 I CONTROL  [initandlisten]     target_arch: x86_64
2016-10-06T11:47:44.446-0400 I CONTROL  [initandlisten] options: { repair: true, storage: { dbPath: "E:\data\Ndata", engine: "wiredTiger" } }
2016-10-06T11:47:44.473-0400 I STORAGE  [initandlisten] Detected WT journal files.  Running recovery from last checkpoint.
2016-10-06T11:47:44.474-0400 I STORAGE  [initandlisten] journal to nojournal transition config: create,cache_size=28G,session_max=20000,eviction=(threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,lo
g_size=2GB),statistics_log=(wait=0),
2016-10-06T11:47:44.643-0400 E STORAGE  [initandlisten] WiredTiger (0) [1475768864:643758][7112:1999909744], txn-recover: wt_snappy_decompress: stored size exceeds buffer size
2016-10-06T11:47:44.644-0400 E STORAGE  [initandlisten] WiredTiger (0) [1475768864:644758][7112:1999909744], txn-recover: WiredTiger is unable to read the recovery log.
2016-10-06T11:47:44.646-0400 E STORAGE  [initandlisten] WiredTiger (0) [1475768864:646758][7112:1999909744], txn-recover: This may be due to the log files being encrypted, being from an older version or due to corruption on disk
2016-10-06T11:47:44.647-0400 E STORAGE  [initandlisten] WiredTiger (0) [1475768864:647758][7112:1999909744], txn-recover: You should confirm that you have opened the database with the correct options including all encryption and compression options
2016-10-06T11:47:44.652-0400 E STORAGE  [initandlisten] WiredTiger (-31802) [147
5768864:652758][7112:1999909744], txn-recover: Recovery failed: WT_ERROR: non-specific WiredTiger error
2016-10-06T11:47:44.675-0400 I -        [initandlisten] Assertion: 28718:-31802: WT_ERROR: non-specific WiredTiger error
2016-10-06T11:47:44.676-0400 I STORAGE  [initandlisten] exception in initAndListen: 28718 -31802: WT_ERROR: non-specific WiredTiger error, terminating
2016-10-06T11:47:44.677-0400 I CONTROL  [initandlisten] dbexit:  rc: 100



 Comments   
Comment by Kelsey Schubert [ 19/Nov/16 ]

Hi hparik11@hawk.iit.edu,

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

Regards,
Thomas

Comment by Kelsey Schubert [ 06/Oct/16 ]

Hi hparik11@hawk.iit.edu,

Thank you for reporting this issue – it appears that the MongoDB data files have become corrupt in some way. I've put together a list of questions that will help us better understand what has happened here. However, please note that in cases like this, it can be challenging to determine the root cause of this issue and data recovery may not be feasible.

  1. Was there an observed error that precipitated this corruption, eg power failure?
  2. What kind of underlying storage mechanism are you using? Are the storage devices attached locally or over the network? Are the disks SSDs or HDDs? What kind of RAID and/or volume management system are you using?
  3. Would you please check the integrity of your disks?
  4. Has the database always been running MongoDB 3.2.10? If not, please describe the upgrade/downgrade cycles the database has been through.
  5. Have you manipulated (copied or moved) the underlying database files? If so, was mongod running?
  6. Have you ever restored this instance from backups?
  7. Would you be able to provide the complete $dbpath for us to investigate this issue?

In addition, please provide the following information for the affected node:

  • configuration file
  • complete logs starting before the corruption was observed
  • an archive of the diagnostic.data directory

I've created a secure upload portal where you can provide the configuration file, logs, and diagnostic.data. Files uploaded to this portal are only visible to MongoDB employees investigating this issue and are routinely deleted after some time.

Thank you,
Thomas

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