[SERVER-39711] WiredTiger error (-31802) [1550747431:604974][82:0x7f30a4b8ccc0], file:WiredTiger.wt, connection: unable to read root page from file:WiredTiger.wt: WT_ERROR: non-specific WiredTiger error Created: 21/Feb/19  Updated: 26/Feb/19  Resolved: 26/Feb/19

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

Type: Bug Priority: Major - P3
Reporter: Diego Rozzini Pires Assignee: Danny Hatcher (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File WiredTigerFiles.tgz     File repair_attempt.tar    
Operating System: ALL
Participants:

 Description   

After a crash on docker container,  I cant start mongo again.

I've tried statrt it using '–repair' but without success. I'getting this log:

2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] MongoDB starting : pid=82 port=27017 dbpath=/data/db 64-bit host=mongo-order-0ic55
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] db version v3.4.1
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] git version: 5e103c4f5583e2566a45d740225dc250baacfbd7
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1t  3 May 2016
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] allocator: tcmalloc
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] modules: none
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] build environment:
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten]     distmod: debian81
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten]     distarch: x86_64
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten]     target_arch: x86_64
2019-02-21T08:10:31.568-0300 I CONTROL  [initandlisten] options: {}
2019-02-21T08:10:31.579-0300 I -        [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-02-21T08:10:31.582-0300 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=7302M,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,log_size=2GB),statistics_log=(wait=0),
2019-02-21T08:10:31.604-0300 E STORAGE  [initandlisten] WiredTiger error (-31802) [1550747431:604974][82:0x7f30a4b8ccc0], file:WiredTiger.wt, connection: unable to read root page from file:WiredTiger.wt: WT_ERROR: non-specific WiredTiger error
2019-02-21T08:10:31.605-0300 E STORAGE  [initandlisten] WiredTiger error (0) [1550747431:605015][82:0x7f30a4b8ccc0], file:WiredTiger.wt, connection: WiredTiger has failed to open its metadata
2019-02-21T08:10:31.605-0300 E STORAGE  [initandlisten] WiredTiger error (0) [1550747431:605026][82:0x7f30a4b8ccc0], file:WiredTiger.wt, connection: This may be due to the database files being encrypted, being from an older version or due to corruption on disk
2019-02-21T08:10:31.605-0300 E STORAGE  [initandlisten] WiredTiger error (0) [1550747431:605033][82:0x7f30a4b8ccc0], file:WiredTiger.wt, connection: You should confirm that you have opened the database with the correct options including all encryption and compression options
2019-02-21T08:10:31.607-0300 I -        [initandlisten] Assertion: 28595:-31802: WT_ERROR: non-specific WiredTiger error src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 267
2019-02-21T08:10:31.619-0300 I STORAGE  [initandlisten] exception in initAndListen: 28595 -31802: WT_ERROR: non-specific WiredTiger error, terminating
2019-02-21T08:10:31.619-0300 I NETWORK  [initandlisten] shutdown: going to close listening sockets...
2019-02-21T08:10:31.619-0300 I NETWORK  [initandlisten] removing socket file: /tmp/mongodb-27017.sock
2019-02-21T08:10:31.619-0300 I NETWORK  [initandlisten] shutdown: going to flush diaglog...
2019-02-21T08:10:31.619-0300 I CONTROL  [initandlisten] now exiting
2019-02-21T08:10:31.619-0300 I CONTROL  [initandlisten] shutting down with code:100



 Comments   
Comment by Danny Hatcher (Inactive) [ 26/Feb/19 ]

Hello Diego,

That's great to hear! In the future, we strongly recommend using a replica set for storing data that is important to you. That way, even if you lose one node, you can simply resync from a different working node and experience little if any downtime. I also recommend upgrading to our most recent release of 3.4 which is 3.4.19 as it contains many different bug fixes and performance improvements.

Have a great day,

Danny

Comment by Diego Rozzini Pires [ 26/Feb/19 ]

Sorry for delay.

 

It worked, perfectly. 

 

Thank You!!!!

Comment by Danny Hatcher (Inactive) [ 22/Feb/19 ]

Hello drozzini,

Thank you for your report. I've attached a repair_attempt.tar of the files you provided. Please extract these files and replace them in your $dbpath and let us know if it resolves the issue.

Thank you,

Danny

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