This document was generated from CDN thread
Created by: Cody Burger on 12-11-2012 08:59:22 AM
Hello again,
We are trying to backup our databases using mongobackup, however whenever we run the command on step 2 and step 3, it kicks back the following error:
[root@uu-qjson1 ~]# /usr/bin/mongodump -h 127.0.0.1:27000 -o /opt/mongo_backup/ --oplog
connected to: 127.0.0.1:27000
all dbs
DATABASE: quad to /opt/mongo_backup/quad
quad.system.users to /opt/mongo_backup/quad/system.users.bson
1 objects
quad.system.indexes to /opt/mongo_backup/quad/system.indexes.bson
16 objects
quad.contactList to /opt/mongo_backup/quad/contactList.bson
95 objects
quad.posts to /opt/mongo_backup/quad/posts.bson
75 objects
quad.event to /opt/mongo_backup/quad/event.bson
153 objects
quad.eventGrouping to /opt/mongo_backup/quad/eventGrouping.bson
77 objects
quad.watchlist to /opt/mongo_backup/quad/watchlist.bson
104 objects
quad.recentShareLists to /opt/mongo_backup/quad/recentShareLists.bson
10 objects
quad.like to /opt/mongo_backup/quad/like.bson
10 objects
quad.people_combo_result to /opt/mongo_backup/quad/people_combo_result.bson
32 objects
quad.comm_combo_result to /opt/mongo_backup/quad/comm_combo_result.bson
32 objects
quad.post_combo_result to /opt/mongo_backup/quad/post_combo_result.bson
32 objects
quad.high_followers to /opt/mongo_backup/quad/high_followers.bson
32 objects
quad.high_members to /opt/mongo_backup/quad/high_members.bson
20 objects
DATABASE: admin to /opt/mongo_backup/admin
local.oplog.rs to /opt/mongo_backup/oplog.bson
0 objects
[root@uu-qjson1 ~]# tar czf json_store.tgz mongo_backup/
tar: mongo_backup: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
[root@uu-qjson1 ~]#
It actually creates the .tgz file in the directory, but the file is only 45 bytes
-rw-r--r-- 1 root root 45 Nov 12 14:53 json_store.tgz
What might I be doing wrong here?
Subject: RE: MongoBackup fails
Replied by: Kalin Sheytanov on 12-11-2012 09:41:20 AM
Hello Cody,
It seems that the error you encounter is comming from the tar tool. Try passing the full path to the mongo backup dir as an argument:
tar czf json_store.tgz /opt/mongo_backup/
Cheers,
Kalin.
Subject: RE: MongoBackup fails
Replied by: Cody Burger on 12-11-2012 09:44:51 AM
I tried that as well, same error, see below:
[root@uu-qjson1 ~]# tar czf json_store.tgz /opt/mongo_backup/
tar: Removing leading `/' from member names
[root@uu-qjson1 ~]# tar czf json_store.tgz opt/mongo_backup/
tar: opt/mongo_backup: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
It again creates the file, but is still only 45 bytes.
Subject: RE: MongoBackup fails
Replied by: Kalin Sheytanov on 12-11-2012 09:53:39 AM
Reading the output you've jsut sent it seems that the first run of the command was successfull. But after that another run was made with the leading slash removed from the path, which would only work if the command is run from the / (root) of the filesystem. The second run oferwrited the archive from the first run thus again the size is 45 bytes. You can add a "v" to the tar options to see the actual files being processed:
tar czvf json_store.tgz /opt/mongo_backup/
Kalin.
Subject: RE: MongoBackup fails
Replied by: Cody Burger on 12-11-2012 10:01:00 AM
Ok, that fixed that issue. Thanks for that.
Now when I try to restore the DB on the new JSON server I get the following error
[admin@uu-cws-json1 ~]$ sudo mongorestore --port 27000 -d quad --drop /opt/mongo_backup/quad/
connected to: 127.0.0.1:27000
ERROR: trying to write to non-master 127.0.0.1:27000
isMaster info: { setName: "jsonstore", ismaster: false, secondary: true, hosts: [ "uu-cws-json1.uu-inc.com:27000", "uu-cws-json2.uu-inc.com:27000" ], arbiters: [ "uu-cws-director1.uu-inc.com:27000" ], primary: "uu-cws-json2.uu-inc.com:27000", me: "uu-cws-json1.uu-inc.com:27000", maxBsonObjectSize: 16777216, ok: 1.0 }
[admin@uu-cws-json1 ~]$
Subject: RE: MongoBackup fails
Replied by: Kalin Sheytanov on 12-11-2012 10:08:02 AM
You are trying to restore the DB on a Secondary JSON node, which is not supported. DBs need to be restored on the primary node: uu-cws-json2.uu-inc.com in your case.
Subject: RE: MongoBackup fails
Replied by: Cody Burger on 12-11-2012 10:10:51 AM
Hmm, I would think uu-cws-json1.uu-inc.com would be our primary. Is there anyway to switch those around? I would hate for json2 to be our primary when it should be json1
Subject: RE: MongoBackup fails
Replied by: Kalin Sheytanov on 15-11-2012 08:02:43 AM
Hello Cody,
In this case it really doesn't matter which node is the primary and which the secondary. Anyway if you want json1 to be the primary node you can do the following:
NOTE: The instructions below assume that you've deployed two json nodes.
Start mongo shell on the primary node and issue the following command:
rs.stepDown(120)
NOTE: This would cause the primary node to step down and the other node should be elected to become master. While stepping down the primary node would drop all active connections. Although the mongo drivers recognize the event and will autamtivally reconnect it is advised this to be run in a mantenance window (for production systems). If more than two json nodes are deployed the proceddure slightly differs.
Cheers,
Kalin.
