[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: |
|
| 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 |