Tue Dec 13 11:44:21 DBClientCursor::init call() failed The output from my db.shutdownServer() locally is: also, I can still open a mongo shell and query my DBS like it was never shut down. the output shows that it 'should be' shut down but when I ps -ef | grep mongo it shows me an active process. On our Ubuntu servers I can shutdown mongo cleanly from the mongo shell with:īut on my Mac, it does not kill the mongod process. Suppose that if user database wil be there then automatically it will after host connection with Robo 3T-1.2 tool.įor example as the screenshot of Robo 3T - 1.1 appears in my environment.I’m running mongo 1.8.2 and trying to see how to cleanly shut it down on Mac. I will somewhere guess that you have been loose your user created database. There is no any user defined database is available with your connected host.Įventhough the files you have generated under the mongodb version is 3.4 & the starting of MongoDB db version is sppearing as v4.0.7. Does anyone know how to do that?ģ) is it possible that we did not recover all the files (or the entire body of all the files) under /data/db?Īny comment or answer will be appreciated!!Īs per your screenshot of Robo3T where only showing the System database (i.e., admin & local). However, if we do copy paste manually, not all the characters are well written they still need to be decrypted. If we could not restore the whole database, extracting data from that file will be still very useful. Does anyone know what's wrong with that?Ģ) collection-23-360946650994865928.wt contains our most important data. And that data truly is from one of collection of database wecaXX.ġ) Now, I'm stuck by dumping the collection. We could see some English or Chinese characters in it. I have checked my directory argument and I found no fault. Note that the command above was indeed ended without. Lt-wt: cursor open(table:collection-23-360946650994865928) failed: No such file or directory /db_backup -C "extensions=" -R dump -f. db_for_wt -C "extensions=" -R salvage collection-23-360946650994865928.wtīased on the article above, it means that we have successfully salvaged this collection. And I created a folder wiredtiger-3.0.0 under db_backup.I installed wiredtiger in folder wiredtiger-3.0.0:Ī) To salvage the collection cd. I created a folder db_backup and put all my files into it. Here is the link Recovering a WiredTiger collection from a corrupt MongoDB installation which introduces how to use WiredTiger to recover collections. Since that didn't work as I expected, I started to find any other tools or approach that may help me. T14:10:04.140+0800 I CONTROL shutting down with code:0Ĭ) After repairing I re-ran mongod -port 27017 -dbpath /data/db -bind_ip_all, it still showed nothing (the same result as step a)). T14:10:04.057+0800 I STORAGE Finished shutting down session sweeper thread T14:10:04.056+0800 I STORAGE Shutting down session sweeper thread T14:10:04.055+0800 I STORAGE WiredTigerKVEngine shutting down T14:10:04.048+0800 I INDEX building index using bulk method build may temporarily use up to 500 megabytes of RAM The result was: T14:10:02.170+0800 I CONTROL Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify -sslDisabledProtocols 'none' > show dbsī) Then I tried to run mongod -port 27017 -dbpath /data/db -bind_ip_all -repair. Here are our files in the directory, and the files was generated under MongoDB version 3.4.Ī) We ran mongod -port 27017 -dbpath /data/db -bind_ip_all and mongo, and expected there should have a user-defined database wecaXX, But, it did not show up. Which was our MongoDB path, and thanks toĮxtundelete, we recovered it and got the directory /data/db. We accidentally deleted the directory rm -rf /data/db
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |