[SERVER-37322] Cannot repair mongodb instance without WiredTiger.turtle file Created: 26/Sep/18  Updated: 26/Sep/18  Resolved: 26/Sep/18

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

Type: Bug Priority: Major - P3
Reporter: Vyacheslav Salakhutdinov Assignee: Nick Brewer
Resolution: Done Votes: 0
Labels: envm, rdi, trct, wtc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: Linux
Participants:

 Description   

After disk outage WiredTiger.turtle became zero-length.

 

# mongod --repair --dbpath /var/lib/mongodb 2018-09-26T17:42:59.267+0300 I CONTROL [initandlisten] MongoDB starting : pid=5450 port=27017 dbpath=/var/lib/mongodb 64-bit host=demo 2018-09-26T17:42:59.267+0300 I CONTROL [initandlisten] db version v3.2.10 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] git version: 79d9b3ab5ce20f51c272b4411202710a082d0317 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] allocator: tcmalloc 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] modules: none 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] build environment: 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] distmod: debian71 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] distarch: x86_64 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] target_arch: x86_64 2018-09-26T17:42:59.268+0300 I CONTROL [initandlisten] options: { repair: true, storage: { dbPath: "/var/lib/mongodb" } } 2018-09-26T17:42:59.295+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-09-26T17:42:59.295+0300 W - [initandlisten] Detected unclean shutdown - /var/lib/mongodb/mongod.lock is not empty. 2018-09-26T17:42:59.295+0300 W STORAGE [initandlisten] Recovering data from the last clean checkpoint. 2018-09-26T17:42:59.295+0300 I STORAGE [initandlisten] Detected WT journal files. Running recovery from last checkpoint. 2018-09-26T17:42:59.295+0300 I STORAGE [initandlisten] journal to nojournal transition config: create,cache_size=1G,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), 2018-09-26T17:42:59.342+0300 I - [initandlisten] Assertion: 28718:2: No such file or directory 2018-09-26T17:42:59.362+0300 I STORAGE [initandlisten] exception in initAndListen: 28718 2: No such file or directory, terminating 2018-09-26T17:42:59.363+0300 I CONTROL [initandlisten] dbexit: rc: 100

Is it possible to repair db?



 Comments   
Comment by Vyacheslav Salakhutdinov [ 26/Sep/18 ]

I restored my collection data with this guide:

http://www.alexbevi.com/blog/2016/02/10/recovering-a-wiredtiger-collection-from-a-corrupt-mongodb-installation/

 

Also I see that added ability to recovery metadata:

https://jira.mongodb.org/browse/SERVER-35629

Maybe there is a possibility to restore the metadata manually for whole db?

Comment by Nick Brewer [ 26/Sep/18 ]

megazoll Thanks for the platform info. Unfortunately there's not a way to extract the collection data without the underlying metadata that is used to interpret it. Sorry we can't be of more help here - let us know if you have any additional questions.

-Nick

Comment by Vyacheslav Salakhutdinov [ 26/Sep/18 ]

Debian on VM(KVM).

 

 

If there is no way to repair whole instance, Is there any chance to extract data from some collection?

Comment by Nick Brewer [ 26/Sep/18 ]

megazoll The WiredTiger.turtle file contains metadata that is used to interpret the WiredTiger.wt file, which in turn is used to interpret all other .wt files that store collections and indexes in your dbpath. As such, I'm afraid we don't have a way to repair a database with an empty .turtle file.

Your best option in this case would be to restore from any backups you have available, or to resync this node if it is a member of a replica set.

So that we can better track this issue, it would be useful to confirm the platform on which the mongod is running (virtual machine, container, native hardware, etc). Thanks in advance for any details you can provide.

-Nick

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