Reference:http://dev.guanghe.tv/2016/06/recovering-a-wiredtiger-collection-from-a-corrupt-wt-file.html
Often walk by the river, where not wet shoes. Although it is said that as long as not using the kill -9
kill process, generally will not cause mongodb problem (MONGO itself has to kill to do processing), but the program always run off, perhaps the server restarted or encountered a power outage and so on, may cause the database file corruption.
Of course, the general abnormal shutdown can not be activated when the lock, PID files or TMP Sock file can be done, it is not a problem, the occasional data anomaly--repair also can be (data volume is to build a bunch of indexes when used with caution, Wait a long time to throw you a repair failure is the most likely to cause people to crash ... ), and actually turned on the journal of the case of non-normal shutdown MONGO when there are more useful data file automatic repair function, MongoDB reliability is actually good.
What we're dealing with here is a database that doesn't open journal and also encounters an exception to the WT data file.
According to the MongoDB startup log, WT_SESSION.open_cursor: unable to read root page from file:collection-3659--4168324323017494102.wt: WT_ERROR: non-specific WiredTiger error
is 3659 this wt file head error, how to do? We can replace this damaged WT file if we follow the advice of some expert on "professional database Repair". And guess what's going to happen? WT_SESSION.open_cursor: collection-3659--4168324323017494102.wt read error: failed to read 4096 bytes at offset 42864640: WT_ERROR: non-specific WiredTiger error
, must also be an error, MONGO how may not do the document verification, violent replacement certainly won't work ah ... And how do we go forward? This is the revenue chain of experts, only to this step can reflect their "file repair technology" is valuable ..... OK, not much to say, repair a small file openings on the four-digit start, said nothing can endure ... Next we do it ourselves, step by step to open the MongoDB database repair from the start to the Discard series tutorial.
The following steps can be recovered by directly reading the WT file to the corresponding collection. The directory layout of the WT engine data for MongoDB can be used here for tuition.
1. Preparation work 1.1 WT Utility KIT
The WT utility kit is the core tool used in this article. Below is the Ubuntu operation example, the compilation process, is nothing more than to install some necessary dependencies according to the error message, generally as long as there is GCC, g++ such as the compilation of necessary tools on the OK, the only more special dependence is the snappy of the Google home, Because the WT engine default table data compression method is snappy (instead of zlib).
wget http://source.wiredtiger.com/releases/wiredtiger-2.7.0.tar.bz2tar xvf wiredtiger-2.7.0.tar.bz2 && cd wiredtiger-2.7.0sudo apt-get install libsnappy-dev build-essential./configure --enable-snappymake
1.2 Files to recover
Be prepared to recover and collection*****.wt
read the necessary _mdb_catalog.wt
,, sizeStorer.wt
storage.bson
WiredTiger
WiredTiger.basecfg
WiredTiger.lock
WiredTiger.turtle
,,,, WiredTiger.wt
,, and We can put these files into a new directory, for example, in this case mongo_bak
, the directory structure is as follows:
collection********.wt_mdb_catalog.wtsizeStorer.wtstorage.bsonWiredTigerWiredTiger.basecfgWiredTiger.lockWiredTiger.turtleWiredTiger.wt
2. Start doing 2.1 "salvage" the part that can be recovered
./wt -v -h ../mongo-bak -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R salvage collection******.wt
This step will read what we have specified collection*****.wt
, ignore any data that cannot be recovered, and then overwrite the new data back. Of course you can also modify the parameters so that it writes the salvage file to another place.
Running the above command will output WT_SESSION.salvage 639400
The result, which is actually all the data that can be recovered. But you can't read this directly to MongoDB right now.
2.2 Make the necessary data formatting adjustments
Because the wt file generated in the previous step is not available to read directly from MongoDB, we'll use WT's dump and load tools to get them into MongoDB in the next few steps.
2.2.1 WT---dump
./wt -v -h ../mongo-bak -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R dump -f ../collection.dump collection******
This step will dump the healthy wt file we just recovered to the file of the parent directory collection.dump
(of course, what is the name of this file, where do you decide, next you can find it). Note This step of the specified collection do not need to write the WT extension, the program is very intimate with wood, save 3 times to hit the keyboard of the physical energy can do a lot of things ... I know you're all copied and pasted ...
Also note that this step of the program is not any state output (if you see an estimate is definitely a false hint ...). If you want to see progress, you can use commands such as the shell to speculate on the progress of the ls -l
collection.dump
file, and to give you a sense of security that some of the programs actually run successfully.
2.2.2 A new collection
This step is mainly for the next load to prepare: We want to create a new database, and then import the data from the previous dump, and then there are a few key and ghost animal steps, will be mentioned later, so this step is to do it honestly.
Here, let's start with a new MONGO instance, and I'll give you a chestnut to do this:
mongod --dbpath tmp-mongo --storageEngine wiredTiger --nojournal
Then we'll connect to this instance and create a new collection
mongo> use Recovery> db.brokedCollection.insert({test: 1})> db.brokedCollection.remove({})> db.brokedCollection.stats()
We created a new database called recovery, and inserted the removed documents, so the data files for those collections would be generated. Use the stats () method to see the name of the WT file for the collection, of course, because we only use a collection, so run to the tmp-mongo
directory next to ls
know this collecion corresponding WT file is which ... Why do you know this? Of course, the next step is to use ...
2.2.3 Dump---new WT
The next is the time to witness the miracle: Our data will soon be able to reproduce the MONGO!
./wt -v -h ../tmp-mongo -C "extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]" -R load -f ../collection.dump -r collection******
This step is to read the previously turned dump file into the collection file generated in the previous step, so-h specifies, of course, the path of the new MONGO instance we used in the previous step. To do this, you need to close the MONGO, otherwise the MONGO process will occupy the WT file does not allow you to operate.
This operation is a progress show.table:collection-******: 1386220
Come and witness the miracle: now it's time to start this MONGO instance in 2.2.2.
mongo> show dbs //应该可以看到Recovery有数据了> use Recovery> show collections //应该可以看到brokedCollection里有数据了> db.brokedCollection.count() //是0?呐尼?
The moment you see 0, you're starting to get nervous again, don't worry. We slowly, if we can solve the problem by this step, why do we have to toss out 2.2.2 this step.
> db.brokedCollection.find({}, {_id: 1})
Then execute this one to see the data, so I guess you'll have hope again, and then we'll go ahead and let the Miracle 2 show up:
2.3 Perfect
Note In order to prevent errors, perform the following steps to ensure that the MongoDB version is not less than 3.2 (because the 3.2 version is built based on WiredTiger2.7).
mongodump
mongorestore --drop
Yes, it's that simple, and then we can verify the miracle.
mongo> show dbs> use Recovery> show collections> db.brokedCollection.count()
Come back this time, everything is OK ... Next you can restore to any place you want to restore, and how to use it is free to play.
3 Call it Off
Knock it off, you are exhausted.
Perhaps you have been inspired by the above steps to think of more interesting ways to recover, but life is too short to be enough ...
MongoDB Usage Recommendations
To the important database of the machine before the operation must be pre-backup, and never thought of the loss to a minimum; and, unless it's really not. Care data high availability, do not casually shut journal; there are multiple libraries on a single machine it is best to set the Directoryperdb in the configuration file. : True to have a separate folder for each library; If you have a spare machine, try to make a copy set ...
Recover the Wiredtiger collection from the corrupted wt file