How to setup a parallel /shadow db using mixed mongodb versions in replica set?

232 views
Skip to first unread message

Subbu

unread,
Sep 11, 2014, 2:06:07 AM9/11/14
to mongod...@googlegroups.com
Hi,

At present we have Mongodb 2.2 having one replicate set (which is also 2.2). Now I want new add additional replicate set ( which will have new version of Mongodb 2.6+)

Idea is to setup a parallel /shadow db, that will be a new stable version of  Mongodb. As sync data is available into new instance, we plan to retire old Mongodb instance and make it primary

Option#1 ( without using replicate set)
1) Start streaming data into new instance
2) Restore dump from old instance into new Mongodb instance
3) With above steps it should ensure that it is in sync

Now we can decide to switch live traffic directly to new Mongodb instance

Some questions on option#1 approach
> What happens to the update document calls for the data which is not available in the new instance?  Does document get inserted into the collection?
> How to avoid over writing the document when we try to restore from dump

Option#2
Is it possible to keep the new Mongodb instance as a new additional replica set?  It should ideally get data in synced with old Mongodb as we see data consistent, we plan to switch to new instance.

Any suggestion/ pointers/ doc should help us to achieve our requirement. I have seen below docs...

http://docs.mongodb.org/manual/release-notes/2.4-upgrade/
http://docs.mongodb.org/manual/release-notes/2.6-upgrade/

Thanks,
Subbu

Virendra Agarwal

unread,
Sep 11, 2014, 2:35:10 AM9/11/14
to mongod...@googlegroups.com
Hi Subbu,

Please try not to use mixed version for a longer time as in case of sharding your chunk migration can show unexpected behavior.
I would suggest first check your db with compatibility for version 2.6.4
They have provided a command for it.
I faced an issue as one of my document was having an empty field like:
{
 count : 5
"",4
}
this  resulted in invalid json in oplog and my replica did not came up till this record was override with new updates in oplog.

If you are not using sharding and data compatibility is good you can have two different version for shorter time but keep your primary on latest version so that your oplog will be updated with this.
Later on you should replace your old version replica with latest version too.

I recently did it so was trying to share my experience.

Regards
Viren

Virendra Agarwal

unread,
Sep 11, 2014, 2:36:49 AM9/11/14
to mongod...@googlegroups.com
Also do not keep 2.2 and 2.6 in parallel use at least 2.4 and.
So first update all  your mongo instances with 2.4 than go for 2.6 on new replica.

Will Berkeley

unread,
Sep 11, 2014, 10:51:09 AM9/11/14
to mongod...@googlegroups.com
I'd suggest just following the instructions in the two links you posted because those are the official and tested procedures. If you want to test how 2.6 will operate, you should set up a QA replica set separate from the production one instead of trying to set up a replica set with mixed versions. If you have a production replica set with mixed versions of MongoDB, what you're really doing is testing how mixed versions work together in a replica set, not how the new version will behave, and you're doing the testing in production.

The upgrade procedure essentially involves replacing secondaries one-by-one with upgraded binaries, then changing primary and upgrading the old primary. If you do that, you can start up a >2.2 mongod on top of the old data files. There's no need for migration of data. Note that you must upgrade 2.2->2.4->2.6; you cannot jump from 2.2 to 2.6. There's a helper called db.upgradeCheckAllDBs in the 2.6 mongo shell that will check your data for problems like Virendra's empty field name "" (the handling of such field names changed 2.4->2.6).

-Will

Subbu

unread,
Sep 11, 2014, 1:02:01 PM9/11/14
to mongod...@googlegroups.com

Thanks for your suggestions.  In any case I was planning to do on stage environment.

let me stick to standard tested procedures,

Subbu

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/2a6ca4da-c2de-45ee-9096-4ca0523c1ec4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages