I am trying to run this command from a remote ssh
mongodump --host mongodb1.example.net --port 27017 --username user --password pass --out /opt/backup/mongodump-2013-10-24
However, all I am getting is blank folders for each collections.
What am I doing wrong?
Info (if it matters):
Source Mongodb is on Windows Server
And SSH is of a remote Ubuntu Machine
Here is the terminal output:
connected to: ip.ip.ip.ip:27017
Thu Feb 18 00:46:01.757 all dbs
Thu Feb 18 00:46:01.809 DATABASE: admin to /opt/backup/mongodump-2013-10-24/admin
Thu Feb 18 00:46:01.903 DATABASE: anthony_data to /opt/backup/mongodump-2013-10-24/anthony_data
Thu Feb 18 00:46:02.004 DATABASE: temp_data to /opt/backup/mongodump-2013-10-24/temp_data
Thu Feb 18 00:46:02.104 DATABASE: zoomy to /opt/backup/mongodump-2013-10-24/zoomy
So it creates empty folder for all collections. But there is no bson in it
Check that your copy of mongodump and the database itself is the same version.
I had the exact same problem (complete with no terminal output or logs) when I tried to do a dump of a mongo 3.2.4 server with a 2.4.1 mongodump client. Removing the older client and installing the newer one resolved it immediately.
I was using the default mongodb-client deb package with Ubuntu. I removed those and installed the mongodb-org-tools package from mongodb.com https://docs.mongodb.com/master/tutorial/install-mongodb-on-ubuntu/?_ga=2.36209632.1945690590.1499275806-1594815486.1499275806
They have other install instructions for your specific OS if you are not on Ubuntu https://www.mongodb.com/download-center?jmp=nav#community
Related
I use pip3 install pgadmin4==4.30 to install pgadmin in my ubuntu. And I want to backup my remote server data by Tools-Backup in pgadmin, which is equal to the following command.
/usr/bin/pg_dump --file "~/demo.backup" --host "127.0.0.1" --port "42885" --username "postgres"....
However there is an error says:pg_dump: sever version:11.7; pg_dump version: 10.3(Ubuntu-10.3-1). One thing that puzzles me is I don't have version 11.7 installed at all. Here is the output of ls -la /usr/bin/pg_dump
0 lrwxrwxrwx 1 root root 34 Mar 2 18:05 /usr/bin/pg_dump -> /usr/lib/postgresql/10/bin/pg_dump
And there is only one version(10) in /usr/lib/postgresql folder. Anyone can tell me how I can fix this? I have tried every solution of this and neither of them worked out.
Just upgraded to mongo 3.0, but mongoexport gives us a the following error: "Failed: read tcp 127.0.0.1:27020: i/o timeout" after outputting some documents (not always the same amount). mongoexport is connecting to a sharded cluster of 4 standalone mongod servers with 3 mongod config servers
[root#SRV]$ mongoexport --host
localhost:27022,localhost:27021,localhost:27020 --db horus
--collection users --type json --fields _id | wc -l
2015-03-09T12:41:19.198-0600 connected to:
localhost:27022,localhost:27021,localhost:27020
2015-03-09T12:41:22.570-0600 Failed: read tcp 127.0.0.1:27020: i/o
timeout
15322
The versions we are using are:
[root#MONGODB01-SRV]# mongo --version MongoDB shell version: 3.0.0
[root#SRV]$ mongoexport --version mongoexport version: 3.0.0 git
version: e35a2e87876251835fcb60f5eb0c29baca04bc5e
[root#SRV]$ mongos --version MongoS version 3.0.0 starting: pid=47359
port=27017 64-bit host=SRV (--help for usage) git version:
a841fd6394365954886924a35076691b4d149168 OpenSSL version: OpenSSL
1.0.1e-fips 11 Feb 2013 build sys info: Linux ip-10-181-61-91 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 BOOST_LIB_VERSION=1_49
Tried with a 2.6 mongoexport in another server against our mongod3.0 and mongos3.0 and works fine
This is an old question but I wanted to answer. Maybe this answer will help one of us. It might be caused by someone else trying to write to the collection you are writing. I had a smilar problem. After a long research I realised that a user with higher role was trying to write in the sametime and because his/her role is more important than mine ones request were done and mine are given IO exception.
Try closing the ports first: eg. killall -9 node
I am experimenting with meteor and have deployed my app to meteor's servers. The app is a simple dynamic filtering engine where the data came from a TSV file. On my home machine, I used mongoimport (localhost:3001) to import the TSV into a local db but on the meteor servers, I received a fresh new empty database. I'm wondering how to import a TSV to a database hosted on meteors servers. I'm sure there are security peculiarities dealing with a publicly provided hosting service and guess that's my issue.
I have logged into my developer account on the meteor servers via the terminal on OSX, yielding server information like: production-db-c1.meteor.io:27017/myApp_meteor_com
With that server info, I follow on with ./mongoimport like so: (not a cut and paste so ignore typos)
./mongoimport --host myApp_meteor_com/production-db-c1.meteor.io:27017 --collection myCollection -u User -p Pass --type tsv --headerline --file blah.tsv
The User/Pass info I obtained by first adding myself as a user with 'readWrite' access and then querying the db.system.users collection on the meteor servers for my app. There were three users in the collection, one of which was named, "myApp_meteor_com", one I added myself and another that apparently was the connected terminal client. I tried each user/pass combinations in the ./mongoimport string above.
*cough It's not really called 'myApp' but you get the idea
Here's the long winded echo from the terminal after executing mongoimport
Thu Mar 6 12:38:38.412 kern.sched unavailable
Thu Mar 6 12:38:38.415 starting new replica set monitor for replica set myApp_meteor_com with seed of production-db-c1.meteor.io:27017
Thu Mar 6 12:38:38.467 successfully connected to seed production-db-c1.meteor.io:27017 for replica set myApp_meteor_com
Thu Mar 6 12:38:38.518 warning: node: production-db-c1.meteor.io:27017 isn't a part of set: myApp_meteor_com ismaster: { setName: "production-c", ismaster: true, secondary: false, hosts: [ "production-db-c1.meteor.io:27017", "production-db-c3.meteor.io:27017", "production-db-c2.meteor.io:27017" ], arbiters: [ "production-dbarb-c2.meteor.io:27017", "production-dbarb-c1.meteor.io:27017" ], primary: "production-db-c1.meteor.io:27017", me: "production-db-c1.meteor.io:27017", maxBsonObjectSize: 16777216, maxMessageSizeBytes: 48000000, localTime: new Date(1394131118501), ok: 1.0 }
Thu Mar 6 12:38:40.518 warning: No primary detected for set myApp_meteor_com
Thu Mar 6 12:38:40.519 All nodes for set myApp_meteor_com are down. This has happened for 1 checks in a row. Polling will stop after 29 more failed checks
Thu Mar 6 12:38:40.519 replica set monitor for replica set myApp_meteor_com started, address is myApp_meteor_com/
couldn't connect to [myApp_meteor_com/production-db-c1.meteor.io:27017] connect failed to replica set myApp_meteor_com/production-db-c1.meteor.io:27017
Any help from meteor/mongodb experts is greatly appreciated.
Highlighting these to make it clear:
Thu Mar 6 12:38:38.518 warning: node: production-db-c1.meteor.io:27017 isn't a part of set: myApp_meteor_com ismaster: { setName: "production-c", ismaster: true, (...)
Thu Mar 6 12:38:40.518 warning: No primary detected for set myApp_meteor_com
You are connecting to the primary, so that is okay. But you have the wrong name for the replica set. The first warning tells you the name of the replica set ("production-c") that this host is a member of and also dumps the configuration list of members.
A better connection argument would be:
./mongoimport --host production-c/production-db-c1.meteor.io,production-db-c3.meteor.io, production-db-c2.meteor.io --collection myCollection -u User-p Pass --type tsv --headerline --file blah.tsv
As this contains some seed list info in the event your current primary was switched to a secondary.
The above helped me out quite a bit, but I ran into authentication issues. So after a bit more research into how the meteor servers issue temporary user/ passwords, I finally was able to import a TSV file into my meteor deployed app's mongoDB.
The "key" for me was to use:
meteor mongo --url myApp
in order to gain a user/pass. It is my understanding that when this command is run, a new user/pass is created each time on the meteor servers and is only good for a very short while (60 secs?). When I ran that, I received this echo at the command prompt
mongodb://client-faddb071:a74c4b2a-15bc-2dcf-dc58-b5369c9ebee3#production-db-c1.meteor.io:27017/myApp_meteor`_com
From that info I was able to extract the username: "client-faddb071" and the password "a74c4b2a-15bc-2dcf-dc58-b5369c9ebee3"
and then in another terminal window (because the user/pass doesn't last long), I was ready to go with the mongo import command:
> ./mongoimport --host production-db-c1.meteor.io:27017 --username client-faddb071 --password a74c4b2a-15bc-2dcf-dc58-b5369c9ebee3 --db myApp_meteor_com --collection myCollection --drop --type tsv --headerline --file /path/to/file.tsv
That worked verbatim for me and 3888 records from the TSV were successfully loaded into my meteor hosted mongoDB. Thanks all for the input, it all contributed to my final knowledge and success.
I just installed Arch Linux today. I'm setting up my development stack, and I'm stuck with mongodb.
I have followed this wiki when installing:
https://wiki.archlinux.org/index.php/MongoDB#Installing_MongoDB
When I try to get into mongo console, I get this:
jan#arch:~$ mongo
MongoDB shell version: 2.4.5
connecting to: test
Tue Jul 9 19:38:13.365 JavaScript execution failed: Error: couldn't connect to server 127.0.0.1:27017 at src/mongo/shell/mongo.js:L112
exception: connect failed
jan#arch:~$
What am I missing here?
EDIT: I figured out when I run mongod directly from terminal, it starts server fine. However the systemctl start mongodb doesn't start it.
Okay, I've figured it out by scanning journalctl output:
ul 09 19:49:33 arch mongod[1122]: all output going to: /var/log/mongodb/mongod.log Jul 09 19:49:33 arch mongod[1122]: can't open [/var/log/mongodb/mongod.log] for log file: errno:13 Permission denied Jul 09 19:49:33 arch mongod[1122]: Bad logpath value: "/var/log/mongodb/mongod.log"; terminating.
So I searched for user that might be utilized by mongodb:
jan#arch:~$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
mongodb:x:998:2::/var/lib/mongodb:/bin/bash
And chowned required folders:
jan#arch:~$ sudo chown -R mongodb:x /var/log/mongodb/
jan#arch:~$ sudo chown -R mongodb:x /var/lib/mongodb/
Started it again:
jan#arch:~$ sudo systemctl start mongodb
It works now.
jan#arch:~$ mongo
MongoDB shell version: 2.4.5
connecting to: test
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
>
I was running MongoDB v2.0.4.
I installed v2.2.2 and restarted.
The mongod process is running fine. Client applications are connecting and functioning fine.
But the mongo shell bombs out.
$: ~ mongo localhost/da
MongoDB shell version: 2.2.2
connecting to: localhost/da
Illegal instruction
$: ~
My "install" process was to download & unpack the .tgz and simlink all the binaries in bin to /usr/local/bin.
Here's what I see in the log on start.
Thu Jan 3 16:14:54 Mongo DB : starting : pid = 7225 port = 27017 dbpath = /var/lib/mongodb/ master = 0 slave = 0 32-bit
** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
** see http://blog.mongodb.org/post/137788967/32-bit-limitations for more
Thu Jan 3 16:14:54 db version v1.2.2, pdfile version 4.5
Thu Jan 3 16:14:54 git version: nogitversion
Thu Jan 3 16:14:54 sys info: Linux vernadsky 2.6.24-27-server #1 SMP Fri Mar 12 01:45:06 UTC 2010 i686 BOOST_LIB_VERSION=1_40
Thu Jan 3 16:14:54 waiting for connections on port 27017
This is running on a 32bit machine w/ 4GB memory and dual core PIII 1.4GHz processor.
Thinking this could be the 'floating point exception' mentioned on the MongoDB downloads page I tried the legacy-static build. The result is the same.
UPDATE
I think the limitations of running on an older 32 bit system make running v2.2.2 too unstable. The 2GB limit is easily exceeded (as evidenced by 'Got signal: 4' errors) when doing a repair operation or checking journal files on start up.
I've decided to revert to v1.2.2 using the Ubuntu package manager.
References:
https://jira.mongodb.org/browse/SERVER-5639
https://groups.google.com/d/topic/mongodb-user/gaAlONRvVSU/discussion
I had the same problem on Debian Squeeze 6.0.10 , an old 32-bit/i386 machine and with the 10gen distribution of the official mongodb instructions. On the instalation some problems with --configure of mongo-org-server and dependencies Trying to execute mongod "Illegal instruction" and
I had to purge the packages and install the 1.4.4 version through a simple apt-get install mongodb.