服务器Ubuntu,安装了mongodb服务,一切正常。
计划在本地通过robomongo软件链接服务器数据库看数据,显示链接失败,telnet host 27107 也连不上,ping可以ping通。在阿里云上安全策略把27017端口允许访问,依然不能解决问题。
网上搜索,原来是mongodb的bind_ip需要修改,默认是127.0.0.1 即本机,修改成0.0.0.0可以远程连接。
vi /etc/mongodb.conf
找到bind_ip修改。
重启:sudo service mongod restart
9.1号补充:
线上环境不要开这个远程访问,今天中招了。
早上发现数据全没了,看日志:db.getSiblingDB("admin").runCommand( { getLog : "global" } )
看到这些"2017-08-31T15:19:14.815+0800 [conn8] allocating new ns file /var/lib/mongodb/db.ns, filling with zeroes...",
"2017-08-31T15:19:15.055+0800 [FileAllocator] allocating new datafile /var/lib/mongodb/db.0, filling with zeroes...",
"2017-08-31T15:19:15.057+0800 [FileAllocator] done allocating datafile /var/lib/mongodb/db.0, size: 64MB, took 0.001 secs",
"2017-08-31T15:19:15.058+0800 [conn8] build index on: db.files properties: { v: 1, key: { _id: 1 }, name: \"_id_\", ns: \"db.files\" }",
"2017-08-31T15:19:15.058+0800 [conn8] \t added index to empty collection",
感觉是分配新数据了,难道是mongodb的自动机制,超过16M分配新的数据文件?Google了很多,没有找到解决方法。
看数据文件:
-rw------- 1 mongodb nogroup 67108864 Aug 31 14:51 DATA_HAS_BEEN_BACKED_UP.0
-rw------- 1 mongodb nogroup 16777216 Aug 31 14:51 DATA_HAS_BEEN_BACKED_UP.ns
drwxr-xr-x 2 mongodb nogroup 4096 Aug 31 15:19 _tmp/
-rw------- 1 mongodb nogroup 67108864 Sep 1 17:09 db.0
-rw------- 1 mongodb nogroup 16777216 Sep 1 17:09 db.ns
drwxr-xr-x 2 mongodb nogroup 4096 Aug 31 14:51 journal/
-rwxr-xr-x 1 mongodb nogroup 6 Aug 21 14:24 mongod.lock*
查询无果,继续看日志,看到这个:
"2017-08-31T14:51:49.170+0800 [initandlisten] connection accepted from 37.187.129.166:54389 #162 (11 connections now open)",
"2017-08-31T14:51:50.937+0800 [conn162] dropDatabase db starting",
"2017-08-31T14:51:51.149+0800 [conn162] removeJournalFiles",
"2017-08-31T14:51:51.267+0800 [conn162] dropDatabase db finished",
"2017-08-31T14:51:51.267+0800 [conn162] command db.$cmd command: dropDatabase { dropDatabase: 1.0 } keyUpdates:0 numYields:0 locks(micros) W:330507 reslen:53 330ms",
"2017-08-31T14:51:52.221+0800 [conn162] dropDatabase local starting",
"2017-08-31T14:51:52.442+0800 [conn162] removeJournalFiles",
"2017-08-31T14:51:52.456+0800 [conn162] dropDatabase local finished",
"2017-08-31T14:51:52.456+0800 [conn162] command local.$cmd command: dropDatabase { dropDatabase: 1.0 } keyUpdates:0 numYields:0 locks(micros) W:235001 reslen:56 235ms",
"2017-08-31T14:51:53.418+0800 [conn162] dropDatabase admin starting",
"2017-08-31T14:51:53.418+0800 [conn162] removeJournalFiles",
"2017-08-31T14:51:53.420+0800 [conn162] dropDatabase admin finished",
37.187.129.166这是个法国ip,艹,中招了啊,被黑了啊。
继续有意思的:
"2017-08-31T14:51:56.982+0800 [conn162] insert DATA_HAS_BEEN_BACKED_UP.README_PLS query: { email_address: \"[email protected]\", bitcoin_address: \"1Mk61Q8squW8WjSWp3qEAYL6pu9TR1Cro9\", note: \"If you want to recover your data, then send 0.1 BTC to bitcoin-address and send your IP to our email. You don't want that your users/customers to know...\", _id: ObjectId('59a7b20e3f6d6970c52879e1') } ninserted:1 keyUpdates:0 numYields:0 locks(micros) w:302971 302ms",
"2017-08-31T14:51:56.982+0800 [conn162] command DATA_HAS_BEEN_BACKED_UP.$cmd command: insert { insert: \"README_PLS\", documents: [ { email_address: \"[email protected]\", bitcoin_address: \"1Mk61Q8squW8WjSWp3qEAYL6pu9TR1Cro9\", note: \"If you want to recover your data, then send 0.1 BTC to bitcoin-address and send your IP to our email. You don't want that your users/customers to know...\", _id: ObjectId('59a7b20e3f6d6970c52879e1') } ], ordered: true } keyUpdates:0 numYields:0 locks(micros) w:25 reslen:40 303ms",
"2017-08-31T14:51:57.291+0800 [conn162] end connection 37.187.129.166:54389 (10 connections now open)",
哥们让我转比特币才给我恢复数据。
幸亏我这个数据不关键啊,丢了的不要了。如果是宝贵数据的话一定注意安全,不要开这个远程访问功能。