2
You can use HomeBrew, see the official MongoDB HomeBrew page.
Just add the tap:
brew tap mongodb/brew
And then after adding the tap from above, you can then install the Mongo shell with:
brew install mongodb-community-shell
2
For the people who will come here in the future the issue was, I was using MongoDB 4.0 on the local and server was on 4.2:
Starting in version 4.2, mongodump uses Extended JSON v2.0 (Canonical) format for the metadata files. To parse these files for restore, use mongorestore version 4.2+ that supports Extended JSON v2.0 (Canonical or Relaxed mode) format.
...
1
It looks like there was a bug as after upgrading to MongoDB v4.2.1 the issue does not happen any more.
1
The rolling index build procedure is recommended. Here is what they say in the doc:
To minimize the impact of building an index on replica sets and sharded clusters, use a rolling index build procedure as described on Build Indexes on Replica Sets.
for more info:
https://docs.mongodb.com/manual/tutorial/build-indexes-on-replica-sets/
https://docs....
1
The short answer is: No, you will not be blocked.
When performing multi-document write operations, whether through a single write operation or multiple write operations, other operations may interleave.
The long explains are:
Collection is granular level (or the resource).
Whenever there is a write operation, Exclusive (X) lock mode must be applied on ...
1
Answer to all you questions is YES.
You can just add (rs.add()) new nodes to RS and data will be synced. Faster way to do that is create those new nodes from backup/snapshot of old node and then rs.add().
What comes to upgrade, if you are just upgrading to new version of MongoD, there is no need to prepare new nodes and then add them to RS, but of course ...
1
If you absolutely need to give direct database access to someone, then go with option a) and all that it entails.
Else, then go with option b).
Option a) is a poor choice because, as of right now (MongoDB 4.2), permission granularity is still at collection level. This means that if users have write access to the same collection, they can overwrite ...
1
If the problem is related to a remote access, here is the solution for anyone who has the problem
show iptable rules line numbers
sudo iptables -L --line-numbers
The output will be something like this
...
num target prot opt source destination
1 ACCEPT all -- anywhere anywhere ctstate RELATED,...
1
Try this:
use admin
db.system.users.find({}, { db: 1, user: 1})
1
This adds to @Miroslav's answer except that the hostname found in /etc/hostname had to match the hostname found in /etc/hosts (dont forget to reboot when changed).
I was using a common /etc/hosts file for all my servers but wasn't updating the /etc/hostname file to match.
Goodluck
Only top voted, non community-wiki answers of a minimum length are eligible
