Not authorized on execute any commands on new install of MongoDB - mongodb

I have installed MongoDB 3.4 on Windows 10 and I cannot execute any commands to view or create users.
I have followed the documentation to the letter and read as many answers to what seems to be a common problem, but I still cannot solve this problem.
Any help would be appreciated. Below are the command prompt outputs:
Command prompt 1 running with admin rights:
C:\Program Files\MongoDB\Server\3.4\bin>mongod.exe --storageEngine mmapv1 --dbpath C:\mongodb\data\db --directoryperdb -journal
2017-04-01T16:21:46.414+0200 I CONTROL [initandlisten] MongoDB starting : pid=10936 port=27017 dbpath=C:\mongodb\data\db 64-bit host=Acer
2017-04-01T16:21:46.415+0200 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2017-04-01T16:21:46.415+0200 I CONTROL [initandlisten] db version v3.4.3
2017-04-01T16:21:46.416+0200 I CONTROL [initandlisten] git version: f07437fb5a6cca07c10bafa78365456eb1d6d5e1
2017-04-01T16:21:46.416+0200 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1u-fips 22 Sep 2016
2017-04-01T16:21:46.417+0200 I CONTROL [initandlisten] allocator: tcmalloc
2017-04-01T16:21:46.417+0200 I CONTROL [initandlisten] modules: none
2017-04-01T16:21:46.418+0200 I CONTROL [initandlisten] build environment:
2017-04-01T16:21:46.418+0200 I CONTROL [initandlisten] distmod: 2008plus-ssl
2017-04-01T16:21:46.418+0200 I CONTROL [initandlisten] distarch: x86_64
2017-04-01T16:21:46.419+0200 I CONTROL [initandlisten] target_arch: x86_64
2017-04-01T16:21:46.419+0200 I CONTROL [initandlisten] options: { storage: { dbPath: "C:\mongodb\data\db", directoryPerDB: true, engine: "mmapv1", journal: { enabled: true } } }
2017-04-01T16:21:46.429+0200 I JOURNAL [initandlisten] journal dir=C:\mongodb\data\db\journal
2017-04-01T16:21:46.429+0200 I JOURNAL [initandlisten] recover begin
2017-04-01T16:21:46.430+0200 I JOURNAL [initandlisten] info no lsn file in journal/ directory
2017-04-01T16:21:46.430+0200 I JOURNAL [initandlisten] recover lsn: 0
2017-04-01T16:21:46.431+0200 I JOURNAL [initandlisten] recover C:\mongodb\data\db\journal\j._0
2017-04-01T16:21:46.480+0200 I JOURNAL [initandlisten] recover applying initial journal section with sequence number 1
2017-04-01T16:21:46.622+0200 I JOURNAL [initandlisten] recover cleaning up
2017-04-01T16:21:46.622+0200 I JOURNAL [initandlisten] removeJournalFiles
2017-04-01T16:21:46.623+0200 I JOURNAL [initandlisten] old journal file will be removed: C:\mongodb\data\db\journal\j._0
2017-04-01T16:21:46.627+0200 I JOURNAL [initandlisten] recover done
2017-04-01T16:21:46.780+0200 I JOURNAL [durability] Durability thread started
2017-04-01T16:21:46.838+0200 I JOURNAL [journal writer] Journal writer thread started
2017-04-01T16:21:46.880+0200 I CONTROL [initandlisten]
2017-04-01T16:21:46.880+0200 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2017-04-01T16:21:46.881+0200 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2017-04-01T16:21:46.883+0200 I CONTROL [initandlisten]
2017-04-01T16:21:48.911+0200 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory 'C:/mongodb/data/db/diagnostic.data'
2017-04-01T16:21:48.919+0200 I INDEX [initandlisten] allocating new ns file C:\mongodb\data\db\admin\admin.ns, filling with zeroes...
2017-04-01T16:21:49.119+0200 I FTDC [ftdc] Unclean full-time diagnostic data capture shutdown detected, found interim file, some metrics may have been lost. OK
2017-04-01T16:21:49.399+0200 I STORAGE [FileAllocator] allocating new datafile C:\mongodb\data\db\admin\admin.0, filling with zeroes...
2017-04-01T16:21:49.401+0200 I STORAGE [FileAllocator] creating directory C:\mongodb\data\db\admin_tmp
2017-04-01T16:21:49.407+0200 I STORAGE [FileAllocator] done allocating datafile C:\mongodb\data\db\admin\admin.0, size: 64MB, took 0.003 secs
2017-04-01T16:21:49.425+0200 I INDEX [initandlisten] build index on: admin.system.version properties: { v: 2, key: { version: 1 }, name: "incompatible_with_version_32", ns: "admin.system.version" }
2017-04-01T16:21:49.425+0200 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 500 megabytes of RAM
2017-04-01T16:21:49.426+0200 I INDEX [initandlisten] build index done. scanned 0 total records. 0 secs
2017-04-01T16:21:49.427+0200 I COMMAND [initandlisten] setting featureCompatibilityVersion to 3.4
2017-04-01T16:21:49.429+0200 I NETWORK [thread1] waiting for connections on port 27017
Command prompt 2 running with admin rights:
> use admin
switched to db admin
> db.createUser( {
... user: "siteUserAdmin",
... pwd: "password",
... roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
... });
Error coming back is
2017-04-01T16:44:14.281+0200 E QUERY [thread1]
Error: couldn't add user: not authorized on admin to execute command
{ createUser: "siteUserAdmin", pwd: "xxx", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ], digestPassword: false, writeConcern: { w: "majority", wtimeout: 600000.0 } } : _getErrorWithCode#src/mongo/shell/utils.js:25:13
DB.prototype.createUser#src/mongo/shell/db.js:1290:15
#(shell):1:1"
> use admin
> db.getUsers();
2017-04-01T16:52:41.537+0200 E QUERY [thread1] Error: not authorized on admin to execute command { usersInfo: 1.0 } :
_getErrorWithCode#src/mongo/shell/utils.js:25:13
DB.prototype.getUsers#src/mongo/shell/db.js:1537:1
#(shell):1:1
>

Related

MongoDB repair failed due to Invariant failure rs.get() src/mongo/db/catalog/database.cpp

MongoDB Version: 3.4.24
MongoDB hosted on Linux server was abruptly shut down due to the over-utilization of memory.
Initiated the mongodb repair using: sudo mongod -f /etc/mongodrepair.conf --repair
The whole database is of 2.5TB, while repairing/re-indexing the db, close to 2.4TB was successfully repaired but the last 972MB of DB repair was failed due to Invariantfailure error.
Repair Logs
2020-07-04T17:17:07.441+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 50 megabytes of RA$
2020-07-04T17:17:07.448+0000 I INDEX [initandlisten] build index on: test.summary properties: { v: 1, key: { totalVolume: -1 }, name: "totalV$
lume_-1", ns: "test.summary", background: true }
2020-07-04T17:17:07.448+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 50 megabytes of RA$
2020-07-04T17:17:07.456+0000 I INDEX [initandlisten] build index on: test.summary properties: { v: 1, key: { ts: -1 }, name: "ts_-1", ns: "test.summary", background: true }
2020-07-04T17:17:07.456+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 50 megabytes of RA$
2020-07-04T17:17:08.673+0000 I - [initandlisten] Invariant failure rs.get() src/mongo/db/catalog/database.cpp 195
2020-07-04T17:17:08.673+0000 I - [initandlisten]
***aborting after invariant() failure
2020-07-04T17:17:08.717+0000 F - [initandlisten] Got signal: 6 (Aborted).
Restart Logs
2020-07-04T17:39:14.476+0000 I CONTROL [main] ***** SERVER RESTARTED *****
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] MongoDB starting : pid=20485 port=27017 dbpath=/home/db324 64-bit host=ip-*-*-*-*
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] db version v3.4.24
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] allocator: tcmalloc
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] modules: none
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] build environment:
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] distarch: x86_64
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] target_arch: x86_64
2020-07-04T17:39:14.480+0000 I CONTROL [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "-.-.-.-", port: 27017 }, replication: $
oplogSizeMB: 10240, replSetName: "rs1" }, storage: { dbPath: "/home/db324", directoryPerDB: true, engine: "wiredTiger", journal: { enabled$
true }, wiredTiger: { engineConfig: { cacheSizeGB: 108.0 } } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.lo$
" } }
2020-07-04T17:39:14.480+0000 W - [initandlisten] Detected unclean shutdown - /home/db324/mongod.lock is not empty.
2020-07-04T17:39:14.499+0000 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2020-07-04T17:39:14.499+0000 I STORAGE [initandlisten]
2020-07-04T17:39:14.499+0000 I STORAGE [initandlisten] ** WARNING: The configured WiredTiger cache size is more than 80% of available RAM.
2020-07-04T17:39:14.499+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=110592M,session_max=20000,eviction=(threads_min=4,t$
reads_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),verbose=(recovery_progress),
2020-07-04T17:39:14.667+0000 I STORAGE [initandlisten] WiredTiger message [1593884354:667272][20485:0x7fdbcb287580], txn-recover: Main recovery loop$
starting at 73368/128
2020-07-04T17:39:14.667+0000 I STORAGE [initandlisten] WiredTiger message [1593884354:667951][20485:0x7fdbcb287580], txn-recover: Recovering log 733$
8 through 73369
2020-07-04T17:39:14.733+0000 I STORAGE [initandlisten] WiredTiger message [1593884354:733044][20485:0x7fdbcb287580], txn-recover: Recovering log 733$
9 through 73369
2020-07-04T17:39:15.164+0000 E STORAGE [initandlisten] WiredTiger error (-31802) [1593884355:164908][20485:0x7fdbcb287580], test/collectio$
-56-3854974571131417844.wt, WT_SESSION.open_cursor: /home/db324/test/collection-56-3854974571131417844.wt: handle-read: pread: failed $
to read 4096 bytes at offset 28672: WT_ERROR: non-specific WiredTiger error
2020-07-04T17:39:15.164+0000 I - [initandlisten] Invariant failure: ret resulted in status UnknownError: -31802: WT_ERROR: non-specific WiredT$
ger error at src/mongo/db/storage/wiredtiger/wiredtiger_session_cache.cpp 113
2020-07-04T17:39:15.165+0000 I - [initandlisten]
***aborting after invariant() failure
Is there a way to repair/recover the last part of the DB? or
Is there a way to ignore the broken DB? or
Is it possible to cut out the whole 2.4TB data sans the last error db and create a new MongoDB instance with 2.4TB?
I would greatly appreciate the help.
Thanks in Advance
The repair log indicates that it failed building an index on ns: "test.summary",
The other log gives you the file name, and the offset of the error:
/home/db324/test/collection-56-3854974571131417844.wt: handle-read: pread: failed $
to read 4096 bytes at offset 28672
The data after that point in the file is likely unsalvageable. You might try:
Make a backup of the existing files
Remove the file /home/db324/test/collection-56-3854974571131417844.wt
Re-run mongod --repair on this dbpath
If all goes well, it will create a new, empty file for that collection.
If you need to try to salvage that data, after the above succeeds so that you know the rest of the data files are consistent, recopy that file from the backup and attempt repair again.

mongod fails to start with error message "missing UUID"

Mongod has been running as v4 for several months. It is used to record clinical data for patient with neurological diseases, and is essential to the drug trials.
This morning mongo crashed, and upon restarting, mongod refuses to start, on a collection that has a missing UUID. The message is cryptic, as this is not a 3.6 DB. Is there a way to proceed? The sensorTag collection is not really essential, and erasing it would be OK. Is there a way to get mongod to use the DB at all?
Here is the startup message:
2020-05-18T23:23:58.587+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] MongoDB starting : pid=1526 port=23417 dbpath=./db 64-bit host=retro-4-10-19
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] db version v4.0.18
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] git version: 6883bdfb8b8cff32176b1fd176df04da9165fd67
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] allocator: tcmalloc
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] modules: none
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] build environment:
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] distmod: ubuntu1804
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] distarch: x86_64
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] target_arch: x86_64
2020-05-18T23:23:58.590+0000 I CONTROL [initandlisten] options: { net: { bindIp: "127.0.0.1", port: 23417 }, storage: { dbPath: "./db" } }
2020-05-18T23:23:58.591+0000 I STORAGE [initandlisten] Detected data files in ./db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2020-05-18T23:23:58.591+0000 I STORAGE [initandlisten]
2020-05-18T23:23:58.591+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-05-18T23:23:58.591+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2020-05-18T23:23:58.591+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=484M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2020-05-18T23:23:59.519+0000 I STORAGE [initandlisten] WiredTiger message [1589844239:519947][1526:0x7fa98a9fca40], txn-recover: Main recovery loop: starting at 46/768 to 47/256
2020-05-18T23:23:59.635+0000 I STORAGE [initandlisten] WiredTiger message [1589844239:635147][1526:0x7fa98a9fca40], txn-recover: Recovering log 46 through 47
2020-05-18T23:23:59.703+0000 I STORAGE [initandlisten] WiredTiger message [1589844239:703356][1526:0x7fa98a9fca40], txn-recover: Recovering log 47 through 47
2020-05-18T23:23:59.767+0000 I STORAGE [initandlisten] WiredTiger message [1589844239:767605][1526:0x7fa98a9fca40], txn-recover: Set global recovery timestamp: 0
2020-05-18T23:23:59.794+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2020-05-18T23:23:59.807+0000 I CONTROL [initandlisten]
2020-05-18T23:23:59.807+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-05-18T23:23:59.807+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2020-05-18T23:23:59.807+0000 I CONTROL [initandlisten]
2020-05-18T23:23:59.823+0000 F CONTROL [initandlisten] ** IMPORTANT: Collection RetrotopeClinic.sensortags is missing an UUID. We expect all collections to have UUIDs starting in FCV 3.6. Please make sure the FCV is version 3.6 before attempting an upgrade to 4.0; see http://dochub.mongodb.org/core/4.0-upgrade-fcv for more details. If the FCV is already 3.6, please try --repair with a 3.6 binary or initial sync to fix the data files.
2020-05-18T23:23:59.823+0000 I NETWORK [initandlisten] shutdown: going to close listening sockets...
2020-05-18T23:23:59.823+0000 I NETWORK [initandlisten] removing socket file: /tmp/mongodb-23417.sock
2020-05-18T23:23:59.823+0000 I STORAGE [initandlisten] WiredTigerKVEngine shutting down
2020-05-18T23:23:59.823+0000 I STORAGE [initandlisten] Shutting down session sweeper thread
2020-05-18T23:23:59.823+0000 I STORAGE [initandlisten] Finished shutting down session sweeper thread
2020-05-18T23:23:59.901+0000 I STORAGE [initandlisten] Downgrading WiredTiger datafiles.
2020-05-18T23:24:00.088+0000 I STORAGE [initandlisten] WiredTiger message [1589844240:88483][1526:0x7fa98a9fca40], txn-recover: Main recovery loop: starting at 47/2176 to 48/256
2020-05-18T23:24:00.190+0000 I STORAGE [initandlisten] WiredTiger message [1589844240:190325][1526:0x7fa98a9fca40], txn-recover: Recovering log 47 through 48
2020-05-18T23:24:00.250+0000 I STORAGE [initandlisten] WiredTiger message [1589844240:250635][1526:0x7fa98a9fca40], txn-recover: Recovering log 48 through 48
2020-05-18T23:24:00.302+0000 I STORAGE [initandlisten] WiredTiger message [1589844240:302709][1526:0x7fa98a9fca40], txn-recover: Set global recovery timestamp: 0
2020-05-18T23:24:00.477+0000 I STORAGE [initandlisten] shutdown: removing fs lock...
2020-05-18T23:24:00.477+0000 I CONTROL [initandlisten] now exiting
2020-05-18T23:24:00.477+0000 I CONTROL [initandlisten] shutting down with code:62
I did also run with the --repair flag: it said it repaied the sensorTag collection, but no, it didn't, and still failed:
020-05-19T00:09:27.800+0000 I STORAGE [initandlisten] Repairing collection StagServExpress.sensortags
2020-05-19T00:09:27.801+0000 I STORAGE [initandlisten] Verify succeeded on uri table:collection-22-4256855214379632921. Not salvaging.
2020-05-19T00:09:27.805+0000 I INDEX [initandlisten] build index on: StagServExpress.sensortags properties: { v: 2, key: { _id: 1 }, name: "_id_", ns: "StagServExpress.sensortags" }
2020-05-19T00:09:27.806+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 166 megabytes of RAM
2020-05-19T00:09:27.810+0000 I INDEX [initandlisten] build index on: StagServExpress.sensortags properties: { v: 2, unique: true, key: { UUID: 1 }, name: "UUID_1", ns: "StagServExpress.sensortags", background: true }
2020-05-19T00:09:27.810+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 166 megabytes of RAM
2020-05-19T00:09:27.813+0000 I INDEX [initandlisten] build index on: StagServExpress.sensortags properties: { v: 2, key: { nickname: 1 }, name: "nickname_1", ns: "StagServExpress.sensortags", background: true }
2020-05-19T00:09:27.813+0000 I INDEX [initandlisten] building index using bulk method; build may temporarily use up to 166 megabytes of RAM
MongoDB 4.0.18 was released a month ago (April 13). You said:
Mongod has been running as v4 for several months.
Which version were you running for "several months" and how long have you been running 4.0.18 for?
Did you upgrade MongoDB at the same time as you experienced the crash?
Do you have backups?
Assuming you have a backup, reinstate the version of MongoDB that was in use prior to the crash and run it on the data directory as close to the crash as your backups allow.
The error message you are seeing was added in 4.0.13, so if you run 4.0.12 or earlier you shouldn't get this error (but I don't know if your data is corrupted and what other issues might exist).
Functionality does get backported to older versions, so it's possible there are older 4.0 servers that don't have the UUID that the current 4.0 is expecting because the changes were made in 4.0 (or 4.2) and backported to 3.6 but after 4.0.0 came out.

How to fix 'Sessions collection is not set up' error when trying to convert existing mongodb instance to replica set

I have installed the latest version of mongodb (v4.0.5) using the following link
https://docs.mongodb.com/manual/tutorial/install-mongodb-on-red-hat/
Following this now I'm trying to set up replication using the instructions provided in the following tutorial
But as soon as i try the command at point "2.Start your mongod instances in their own shell windows by issuing the following commands"
it gives me the following error
"Sessions collection is not set up; waiting until next sessions refresh interval: Replication has not yet been configured"
Command I used: mongod --replSet rs0 --port 27019 --bind_ip localhost,[MY_IP] --dbpath /srv/mongodb/rs0-2 --smallfiles --oplogSize 128
A more detailed output for the command is as follows:
2018-12-31T15:37:03.618+0530 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] MongoDB starting : pid=xxx port=27017 dbpath=/srv/mongodb/rs0-0 64-bit host=xxx
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] db version v4.0.5
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] git version: xxx
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] allocator: tcmalloc
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] modules: none
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] build environment:
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] distmod: rhel70
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] distarch: x86_64
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] target_arch: x86_64
2018-12-31T15:37:03.623+0530 I CONTROL [initandlisten] options: { net: { bindIp: "localhost,xxx", port: 27017 }, replication: { replSet: "rs0" }, storage: { dbPath: "/srv/mongodb/rs0-0" } }
2018-12-31T15:37:03.624+0530 I STORAGE [initandlisten] Detected data files in /srv/mongodb/rs0-0 created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2018-12-31T15:37:03.625+0530 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=3399M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2018-12-31T15:37:04.683+0530 I STORAGE [initandlisten] WiredTiger message [1546250824:683476][30064:0x7f4cb133db40], txn-recover: Main recovery loop: starting at 5/6144 to 6/256
2018-12-31T15:37:04.796+0530 I STORAGE [initandlisten] WiredTiger message [1546250824:796244][30064:0x7f4cb133db40], txn-recover: Recovering log 5 through 6
2018-12-31T15:37:04.871+0530 I STORAGE [initandlisten] WiredTiger message [1546250824:871037][30064:0x7f4cb133db40], txn-recover: Recovering log 6 through 6
2018-12-31T15:37:04.945+0530 I STORAGE [initandlisten] WiredTiger message [1546250824:945584][30064:0x7f4cb133db40], txn-recover: Set global recovery timestamp: 0
2018-12-31T15:37:04.964+0530 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten]
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten]
2018-12-31T15:37:04.975+0530 I CONTROL [initandlisten]
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten]
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-12-31T15:37:04.976+0530 I CONTROL [initandlisten]
2018-12-31T15:37:04.995+0530 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/srv/mongodb/rs0-0/diagnostic.data'
2018-12-31T15:37:04.996+0530 I REPL [initandlisten] Did not find local voted for document at startup.
2018-12-31T15:37:04.997+0530 I REPL [initandlisten] Rollback ID is 1
2018-12-31T15:37:04.997+0530 I REPL [initandlisten] Did not find local replica set configuration document at startup; NoMatchingDocument: Did not find replica set configuration document in local.system.replset
2018-12-31T15:37:04.997+0530 I CONTROL [LogicalSessionCacheRefresh] Sessions collection is not set up; waiting until next sessions refresh interval: Replication has not yet been configured
2018-12-31T15:37:04.997+0530 I NETWORK [initandlisten] waiting for connections on port 27017
2018-12-31T15:37:04.998+0530 I CONTROL [LogicalSessionCacheReap] Sessions collection is not set up; waiting until next sessions reap interval: config.system.sessions does not exist
I tried following other tutorials where the commands were without the --ip_bind option but i still faced the same error.
I tried searching on the net for this specific error but have not come across any solution for my error.
You need to initiate it with rs.initiate().
Once you launched as you did, you can run this from an other terminal
mongo --eval 'rs.initiate();'
If you are familiar with docker, you can reproduce the error and the initialisation:
docker run --rm -it mongo:4.0 /bin/bash -c "\
mongod --replSet rs0 --fork --logpath /var/log/mongodb/mongod.log &&\
sleep 5 &&\
mongo --eval 'rs.initiate();' &&\
tail -n +0 -f /var/log/mongodb/mongod.log"
I used the --fork to run mongod as a deamon, in order to be able to call the rs.initiate() a bit later

PackStack fails with - Error: Unable to connect to mongodb server

Openstack - Kilo
OS - CentOS Linux release 7.2.1511 (Core)
Applying 10.xx.xxx.xx_mongodb.pp
Applying 10.xx.xxx.xx_redis.pp
10.xx.xxx.xx_mongodb.pp: [ ERROR ]
Applying Puppet manifests [ ERROR ]
ERROR : Error appeared during Puppet run: 10.xx.xxx.xx_mongodb.pp
Error: Unable to connect to mongodb server! (10.xx.xxx.xx:27017)
You will find full trace in log /var/tmp/packstack/20160101-065236-2OHqyr/manifests/10.xx.xxx.xx_mongodb.pp.log
Please check log file /var/tmp/packstack/20160101-065236-2OHqyr/openstack-setup.log for more information
Additional information:
* A new answerfile was created in: /root/packstack-answers-20160101-065237.txt
* Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
* File /root/keystonerc_admin has been created on OpenStack client host 10.xx.xxx.xx. To use the command line tools you need to source the file.
* To access the OpenStack Dashboard browse to 10.xx.xxx.xx/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
* To use Nagios, browse to 10.xx.xxx.xx/nagios username: nagiosadmin, password: d11c096693bb44cd
mabgodb.log detail
2015-12-31T14:18:24.233-0500 [initandlisten] MongoDB starting : pid=34017 port=27017 dbpath=/var/lib/mongodb 64-bit host=vcswin01.samgpunb.symantec.com
2015-12-31T14:18:24.234-0500 [initandlisten]
2015-12-31T14:18:24.234-0500 [initandlisten] ** WARNING: You are running on a NUMA machine.
2015-12-31T14:18:24.234-0500 [initandlisten] ** We suggest launching mongod like this to avoid performance problems:
2015-12-31T14:18:24.234-0500 [initandlisten] ** numactl --interleave=all mongod [other options]
2015-12-31T14:18:24.234-0500 [initandlisten]
2015-12-31T14:18:24.234-0500 [initandlisten] db version v2.6.6
2015-12-31T14:18:24.234-0500 [initandlisten] git version: nogitversion
2015-12-31T14:18:24.234-0500 [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
2015-12-31T14:18:24.235-0500 [initandlisten] build info: Linux c1bg.rdu2.centos.org 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 BOOST_LIB_VERSION=1_53
2015-12-31T14:18:24.235-0500 [initandlisten] allocator: tcmalloc
2015-12-31T14:18:24.235-0500 [initandlisten] options: { command: [ "run" ], config: "/etc/mongodb.conf", net: { bindIp: "127.0.0.1", http: { enabled: false }, port: 27017 }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongod.pid" }, storage: { dbPath: "/var/lib/mongodb", journal: { enabled: true } }, systemLog: { destination: "file", path: "/var/log/mongodb/mongodb.log", quiet: true } }
2015-12-31T14:18:24.235-0500 [initandlisten]
2015-12-31T14:18:24.235-0500 [initandlisten] ** WARNING: Readahead for /var/lib/mongodb is set to 4096KB
2015-12-31T14:18:24.235-0500 [initandlisten] ** We suggest setting it to 256KB (512 sectors) or less
2015-12-31T14:18:24.235-0500 [initandlisten] ** http://dochub.mongodb.org/core/readahead
2015-12-31T14:18:24.236-0500 [initandlisten] journal dir=/var/lib/mongodb/journal
2015-12-31T14:18:24.237-0500 [initandlisten] recover : no journal files present, no recovery needed
2015-12-31T14:18:24.260-0500 [initandlisten] allocating new ns file /var/lib/mongodb/local.ns, filling with zeroes...
2015-12-31T14:18:24.293-0500 [FileAllocator] allocating new datafile /var/lib/mongodb/local.0, filling with zeroes...
2015-12-31T14:18:24.293-0500 [FileAllocator] creating directory /var/lib/mongodb/_tmp
2015-12-31T14:18:24.295-0500 [FileAllocator] done allocating datafile /var/lib/mongodb/local.0, size: 64MB, took 0 secs
2015-12-31T14:18:24.299-0500 [initandlisten] build index on: local.startup_log properties: { v: 1, key: { _id: 1 }, name: "id", ns: "local.startup_log" }
2015-12-31T14:18:24.299-0500 [initandlisten] added index to empty collection
2015-12-31T14:18:24.300-0500 [initandlisten] waiting for connections on port 27017
For now see "Hackery setting up RDO Kilo on CentOS 7.2 with Mongodb up and running as of 01/08/2016"
http://dbaxps.blogspot.com/2016/01/set-up-rdo-kilo-on-centos-72-with.html

MongoDB --dbpath giving access to old data

I have mongo installed on my local machine. When I start the database by running mongod I got this error (that is fairly common, and this site has solutions to workarounds):
$ mongod
mongod --help for help and startup options
2015-01-01T22:31:17.350-0600 [initandlisten] MongoDB starting : pid=2835 port=27017 dbpath=/data/db 64-bit host=hermes
2015-01-01T22:31:17.351-0600 [initandlisten] db version v2.6.4
2015-01-01T22:31:17.351-0600 [initandlisten] git version: nogitversion
2015-01-01T22:31:17.351-0600 [initandlisten] build info: Darwin minimavericks.local 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49
2015-01-01T22:31:17.351-0600 [initandlisten] allocator: tcmalloc
2015-01-01T22:31:17.351-0600 [initandlisten] options: {}
2015-01-01T22:31:17.351-0600 [initandlisten] exception in initAndListen: 10296
*********************************************************************
ERROR: dbpath (/data/db) does not exist.
Create this directory or give existing directory in --dbpath.
See http://dochub.mongodb.org/core/startingandstoppingmongo
*********************************************************************
, terminating
2015-01-01T22:31:17.351-0600 [initandlisten] dbexit:
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: going to close listening sockets...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: going to flush diaglog...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: going to close sockets...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: waiting for fs preallocator...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: lock for final commit...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: final commit...
2015-01-01T22:31:17.351-0600 [initandlisten] shutdown: closing all files...
2015-01-01T22:31:17.352-0600 [initandlisten] closeAllFiles() finished
2015-01-01T22:31:17.355-0600 [initandlisten] dbexit: really exiting now
I created a directory in my development environment at /my/curent/directory/data/db and started mongo again with $ mongod --dbpath /my/curent/directory/data/db, this time producing:
2015-01-01T22:32:31.282-0600 [initandlisten] options: { storage: { dbPath: "./data/db" } }
2015-01-01T22:32:31.319-0600 [initandlisten] journal dir=./data/db/journal
2015-01-01T22:32:31.320-0600 [initandlisten] recover : no journal files present, no recovery needed
2015-01-01T22:32:31.383-0600 [FileAllocator] allocating new datafile ./data/db/local.ns, filling with zeroes...
2015-01-01T22:32:31.383-0600 [FileAllocator] creating directory ./data/db/_tmp
2015-01-01T22:32:31.482-0600 [FileAllocator] done allocating datafile ./data/db/local.ns, size: 16MB, took 0.098 secs
2015-01-01T22:32:31.842-0600 [FileAllocator] allocating new datafile ./data/db/local.0, filling with zeroes...
2015-01-01T22:32:32.756-0600 [FileAllocator] done allocating datafile ./data/db/local.0, size: 64MB, took 0.914 secs
2015-01-01T22:32:33.215-0600 [initandlisten] build index on: local.startup_log properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "local.startup_log" }
2015-01-01T22:32:33.216-0600 [initandlisten] added index to empty collection
2015-01-01T22:32:33.216-0600 [initandlisten] command local.$cmd command: create { create: "startup_log", size: 10485760, capped: true } ntoreturn:1 keyUpdates:0 numYields:0 reslen:37 1852ms
2015-01-01T22:32:33.216-0600 [initandlisten] waiting for connections on port 27017
2015-01-01T22:33:31.402-0600 [clientcursormon] mem (MB) res:33 virt:2635
2015-01-01T22:33:31.402-0600 [clientcursormon] mapped (incl journal view):160
2015-01-01T22:33:31.402-0600 [clientcursormon] connections:0
It's great. Using the mongo shell, I can access my collections that I was working with in this directory, but I can also see all of my other databases from weeks prior (when this directory did not exist) using show dbs. What purpose does the --dbpath option serve if not to isolate where data is stored? Is something weird happening here?
MongoDB requires a data directory to store all data. MongoDB’s default data directory path is \data\db.
To use an alternate dbpath, specify the path in the configuration file (e.g. C:\Program Files\MongoDB\mongod.cfg) or on the command line with the --dbpath option.
Read more about MongoDB Installation
If you are using windows then create data\db folder under C drive.
If you are using your own directory for data then pass full path of the folder as --dbpath argument value.
If MongoDB’s default data directory path "\data\db" is correct but accessing old data means just check your Task Manager.
End all mongo command and restart your mongodb. I tried it, working well