Whoop, Whoop, Whoop, Whoop, Whoop, Whoop, Whoop, Whoop, Whoop, Whoop, Whoop
I was frightened to death and thought I was going to delete the Treasury and run away.
Close mongodb can not use kill-9!!!!
Kill-9!!!!!!!!!
Kill-9!!!!!!!!!!
But what can I do if I use it carelessly? Recover orz slowly.
Reference to a lot of big man's articles:
http://blog.itpub.net/26995414/viewspace-733012/
https://www.cnblogs.com/ctypyb2002/p/9793055.html
After kill-9, it was found that the startup failed! It's been a long time! At last, it's done well! ____________ I was frightened into a cold sweat.
In fact, the main reason is that because of abnormal exit, mongo locked its database to death.
Note: Administrator privileges are required for most of the following operations
Access Administrator Rights:
sudo -s
Then you enter the password.
Exploratory Opening of Database
Normally, the database is placed under / var/lib/mongodb, and the database locked by my kill-9 is the path.
But mongod's default path is / data/db, so enter it directly
/usr/bin/mongod
It can work normally. / data/db is not locked. But there's no data in / data / db, orz
Try to run with the original database:
/usr/bin/mongod --dbpath /var/lib/mongodb/
It failed. That's the problem with the database.
Delete locked files and restore them
Here we delete mongod.lock and storage.bson according to the big man's operation. The content of mongod.lock is the process number that I kill ed.
cd /var/lib/mongodb rm mongod.lock rm storage.bson mongod --dbpath /var/lib/mongodb --repair
In general, that's fine. Then go ahead and restart mongodb.
Then the Big Man had an operation I didn't use:
# cd ./journal # ls -l //Total dosage 84904 -rw-r--r-- 1 mongodb mongodb 86924928 2 Month 2320:47 WiredTigerLog.0000260433 -rw-r--r-- 1 mongodb mongodb 128 2 Month 2320:47 WiredTigerLog.0000260434 -rw-r--r-- 1 mongodb mongodb 128 2 Month 2320:47 WiredTigerLog.0000260435 -rw-r--r-- 1 root root 128 2 Month 2320:47 WiredTigerLog.0000260436 # chown mongodb:mongodb WiredTigerLog.0000260436
The reason for this is that in the data under. / journal, one of the permissions of root is changed from the permission file of that root to mongodb, so that mongodb can be used.
All of my files here are mongodb's permissions, so I don't need this step.
Then restart the service.
Correct mongo closure posture:
Take a note of... Purring
Enter the mongo command:
zzh@server1:~/mongolog$ mongo
MongoDB shell version v3.6.3
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.3
Server has startup warnings:
2019-09-26T11:25:52.180+0800 I STORAGE [initandlisten]
2019-09-26T11:25:52.180+0800 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-09-26T11:25:52.180+0800 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten]
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten]
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** WARNING: This server is bound to localhost.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** Remote systems will be unable to connect to this server.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** Start the server with --bind_ip <address> to specify which IP
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** addresses it should serve responses from, or with --bind_ip_all to
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** bind to all interfaces. If this behavior is desired, start the
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten] ** server with --bind_ip 127.0.0.1 to disable this warning.
2019-09-26T11:25:58.512+0800 I CONTROL [initandlisten]
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten]
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten] ** WARNING: You are running on a NUMA machine.
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten] ** We suggest launching mongod like this to avoid performance problems:
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten] ** numactl --interleave=all mongod [other options]
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten]
>
A bunch of warnings, you can ignore, and finally enter the command line of monggo, enter use admin
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten]
> use admin
Then enter db.shutdownServer();
Then wait, ctrl+C exits. Don't worry, I waited for more than ten seconds before it quit...
The red one below is for you to enter
2019-09-26T11:25:58.514+0800 I CONTROL [initandlisten]
> use admin
switched to db admin
> db.shutdownServer();
server should be down...
2019-09-26T11:28:08.308+0800 I NETWORK [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2019-09-26T11:28:08.308+0800 W NETWORK [thread1] Failed to connect to 127.0.0.1:27017, in(checking socket for error after poll), reason: Connection refused
2019-09-26T11:28:08.308+0800 I NETWORK [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) failed failed
> ^C
bye
And I'll tell you about bye. It's cute.
Then take a look at the process:
zzh@server1:~/mongolog$ ps -efa |grep mongo
zzh 28155 14104 0 12:08 pts/18 00:00:00 grep --color=auto mongo
It's really turned off.