[SERVER-37937] MongoDB fails to start Created: 06/Nov/18  Updated: 14/Nov/18  Resolved: 14/Nov/18

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

Type: New Feature Priority: Major - P3
Reporter: Denis Romanenko Assignee: Danny Hatcher (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File WiredTiger.turtle     File WiredTiger.wt    
Participants:

 Description   

Hello. Mongodb server dont start after server crash

root@mongo:/var/lib/mongodb# mongod --dbpath /var/lib/mongodb --repair

2018-11-06T09:28:40.178+0300 I CONTROL  [initandlisten] MongoDB starting : pid=3775 port=27017 dbpath=/var/lib/mongodb 64-bit host=mongo

2018-11-06T09:28:40.178+0300 I CONTROL  [initandlisten] db version v3.6.5

2018-11-06T09:28:40.178+0300 I CONTROL  [initandlisten] git version: a20ecd3e3a174162052ff99913bc2ca9a839d618

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten] allocator: tcmalloc

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten] modules: none

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten] build environment:

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten]     distmod: debian71

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten]     distarch: x86_64

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten]     target_arch: x86_64

2018-11-06T09:28:40.179+0300 I CONTROL  [initandlisten] options: { repair: true, storage:

{ dbPath: "/var/lib/mongodb" }

}

2018-11-06T09:28:40.180+0300 I -        [initandlisten] Detected data files in /var/lib/mongodb created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.

2018-11-06T09:28:40.180+0300 I STORAGE  [initandlisten]

2018-11-06T09:28:40.180+0300 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine

2018-11-06T09:28:40.180+0300 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem

2018-11-06T09:28:40.180+0300 I STORAGE  [initandlisten] Detected WT journal files.  Running recovery from last checkpoint.

2018-11-06T09:28:40.180+0300 I STORAGE  [initandlisten] journal to nojournal transition config: create,cache_size=1471M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),cache_cursors=false,log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),

2018-11-06T09:28:40.883+0300 E STORAGE  [initandlisten] WiredTiger error (0) [1541485720:883134][3775:0x7fef9686c9c0], txn-recover: WT_COMPRESSOR.decompress: stored size exceeds source size

2018-11-06T09:28:40.884+0300 E STORAGE  [initandlisten] WiredTiger error (-31802) [1541485720:884328][3775:0x7fef9686c9c0], txn-recover: Recovery failed: WT_ERROR: non-specific WiredTiger error

2018-11-06T09:28:40.892+0300 E -        [initandlisten] Assertion: 28718:-31802: WT_ERROR: non-specific WiredTiger error src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 392

2018-11-06T09:28:40.893+0300 I STORAGE  [initandlisten] exception in initAndListen: Location28718: -31802: WT_ERROR: non-specific WiredTiger error, terminating

2018-11-06T09:28:40.893+0300 I NETWORK  [initandlisten] shutdown: going to close listening sockets...

2018-11-06T09:28:40.893+0300 I NETWORK  [initandlisten] removing socket file: /tmp/mongodb-27017.sock

2018-11-06T09:28:40.893+0300 I CONTROL  [initandlisten] now exiting

2018-11-06T09:28:40.893+0300 I CONTROL  [initandlisten] shutting down with code:100

 



 Comments   
Comment by Danny Hatcher (Inactive) [ 07/Nov/18 ]

Hello Denis,

It appears that there is a discrepancy between WiredTiger Journal compressors. If this node is a member of a replica set, I recommend performing an initial sync against another node. If it is a standalone, I recommend deleting the files in the journal directory and attempting to start the server up again. Please note that this latter option may result in data loss if there are documents that have been written to the journal but not yet committed to disk.

Thank you,

Danny

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